Should I choose ActivePerl or Strawberry Perl for Windows? [duplicate]

Answer 1

Strawberry Perl is more Unixy in its approach, and I have been always very happy when I've worked with it.

ActivePerl, however, due to its custom package management system, has been a colossal pain when I've worked with it. This matters when you're in an enterprise environment.

For just messing around, IMO, Strawberry Perl is better. /subjective

Answer 2

Both are great and work the same. Strawberry Perl is known for being able to build XS modules, but you can do that with ActivePerl too if you just install the Visual Studio SDK (or the free Express version).

For that matter, if you have access to Visual Studio, the best you can do is to build Perl from source (it's pretty easy if you read the README) and keep building your modules with the same compiler. That's actually a better idea than having a mixture of compiler/modules.

One thing you have to consider if using ActiveState: If you install it on a server facing the Internet, then you are required to buy a Business license ($1000/year/server as noted by Ron Warshawsky). It doesn't mean it won't work; it's only a matter of being a requirement in the EULA. Many people don't know this and have it installed on Internet-facing servers without buying the corresponding license.

Answer 3

After having used both for years, I'd say, for me at least, ActivePerl is a much more convenient choice. The PPM installer included in ActivePerl allows you to add alternative PPM repositories which will give you access to almost all useful Perl modules available on CPAN - but prepared and tested for Windows. This was for me, in the long run, a much better (and more robust) choice. Even for the Windows version of the Apache HTTP server, there is a precompiled mod_perl (2.0.4) ppm available which will (did for me) work out of the box with ActivePerl 5.12.1 and Apache 2.2.15.

I think I dropped Strawberry Perl after trying to install DBI + DBD::mysql on Windows 7 (which is a no brainer in ActivePerl; just click on the ppms and choose install).

But maybe that's solved by now. And maybe one can choose the directory where Strawberry Perl gets installed (I couldn't).

BTW: for compiling your own Inline or XS stuff, just install the MinGW compiler by ppm (I didn't do that, but it looks interesting).

Addendum: after reading the comment below, I checked Strawberry Perl again and it's now possible to change the installation directory, which is a denoted feature of the 5.12.0 release (which is the actual version). This would solve one important (IMHO) disadvantage of Strawberry Perl (compared to ActivePerl).

Answer 4

If you design your application right, it shouldn't matter which you choose.

A big point might be the versions of various modules that each can provide, or not provide. PPM packages can lag behind CPAN releases, but if you aren't careful, bleeding-edge CPAN releases can break backwards compatibility. Furthermore, sometimes there will be PPM packages for things that just won't build properly under Strawberry Perl (though this implies that the module is poorly designed more often than not).

Just be aware of the versions of any modules you use, and you should be fine, regardless of which you choose.

Answer 5

If you are using the box.com client to sync files, then you probably want (at least at the moment) to go with Strawberry Perl. The ppm executable conflicts with one of the Box.com DLL files. The GUI will not start at all (yielding a Windows message that the "perl ... interpreter has stopped working".) I have also had intermittent problems using the command line version of ppm when the Box.com client is installed.

Answer 6

If Larry Wall uses Strawberry Perl so should you. ;)