3

Can anyone shed light on why people would be making this comment? I've seen several threads on stackoverflow (like this one) where people say this. It seems to me that PPMs are nothing more than pre-compiled versions of modules that are just getting dropped into your perl installation. Assuming they have no external dependencies to a system DLL, what's the big risk?

As far as I can tell PPM does dependency checking when you install a particular module and will install any others that it requires. Seems like the same thing as using .deb or .rpm files on a Linux distro.

EDIT #1:

I found this page regarding the module Wx where they're showing how to use PPM to install Wx for Strawberry Perl. I tried them and they seem to work just fine. I also mixed CPAN modules using PPM and cpanminus, and everything seems fine. Modules such as:

  • Wx
  • DateTime
  • DBI
  • Data::Dumper
  • DBD::AnyData

I'm concluding that the comments regarding the risk of mixing PPM with Strawberry Perl as something that should be taken with a grain of salt, as something that may cause you an issue here or there, but in general its perfectly fine to use PPM modules with Strawberry Perl.

Community
  • 1
  • 1
slm
  • 15,396
  • 12
  • 109
  • 124

2 Answers2

7

PPMs were created (by ActiveState, I think) so that users could install modules with XS extensions or which used external libraries, without needing to have a C compiler or make, or any of the unixy stuff that cpan expects to have present. One of their problems is that ActiveState (or someone) has to have made the PPM for the module you want, and all the modules it uses from CPAN. Sometimes this meant using an older version until they caught up, and sometimes it meant modules just weren't available.

The genius of Strawberry is that it provides a hidden unixy environment that cpan can use to build modules for you, so doing away with the need to package binaries.

This means you get the dependency checking done by cpan, and it becomes much easier (for certain values of easy) to install newer versions of modules, or to link to libraries in odd places, and for many more CPAN modules to be available without any effort from anyone.

The same arguments can be made about using a linux-distro packaging system. If you need a module version that's out of sync with the distro then you're stuck. If you want to use a more up to date Perl, you're stuck. Perl has its own very good packaging system in the CPAN ecosystem, so it really makes sense to use that if you can.

At the same time, sometimes it's more sensible to use a set of provided binary packages, especially if you have to roll out lots of systems, and your Perl install is only a small part of the collection of packages you need to keep track of.

Alex
  • 5,863
  • 2
  • 29
  • 46
  • 2
    What you say about ActivePerl is completely wrong. I've used `cpan` with ActivePerl for as long as I've been using Perl. One doesn't even need to install a compiler anymore as `cpan` will automatically install `mingw`. – ikegami Oct 08 '11 at 07:42
  • I started with ActivePerl 5.6, and that was released before 2000. I don't know when Strawberry Perl came out, but it was *long* after that. – ikegami Oct 08 '11 at 07:55
  • What there wasn't before Strawberry Perl was a free compiler. What Strawberry Perl brought Perl was support for MinGW, for both Strawberry Perl and ActivePerl. In fact, now that MS's compiler is free, ActivePerl gives you the choice of two free compilers. – ikegami Oct 08 '11 at 08:00
  • 1
    Well, there was a free compiler, but you had to install a bunch of stuff yourself and it was a big pain. :) – brian d foy Oct 08 '11 at 12:25
4

PPDs can actually include external libraries (e.g. XML::LibXML's package includes libxml2), so they can be simpler to install.

PPDs are already compiled, so they can be faster to install.

PPDs give you less control since they are prepared by someone else. You are limited to the modules available (which is thankfully a huge swath of what's available) and to the versions available.

I normally hesitate to mix two systems, but I have never encountered a single issue from using both ppm and cpan on the same build.

Just use the one that's convenient for you.

ikegami
  • 367,544
  • 15
  • 269
  • 518
  • I don't use Windows, but I thought the main issue that ActiveState compiled with one compiler, and Strawberry would use another. Mixing the two isn't guaranteed to work out. – brian d foy Oct 08 '11 at 12:27
  • 1
    @brian d foy, They're compatible. I heard sisyphus encountered some incompatibility with C++ bit fields at one point, but I hear mingw is now always called with the MS-compatibility option which makes even bit fields compatible. – ikegami Oct 08 '11 at 18:33