Why is it discouraged to use PPM perl modules with Strawberry perl on Windows?

Question

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.

Answer 1

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.

Answer 2

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.