mstpan 10 - Perl VM deployment
I still roll to disbelieve in dependency heaven.
System perl
Using the perl that came with your system is not necessarily a terrible idea. To be entirely honest, provided it's reasonably recent I'm happy to do so with the caveat that I local::lib all the modules I'm using - so I'm dependent on my system's perl, but not on any other perl* packages.
Debian does really quite well at this these days. Since Ubuntu basically just snapshots debian testing, it also does pretty well these days.
Red Hat derived systems ... a bit less so. Their 'perl' package isn't actually a complete perl install, you need 'perl-core' to get that. Even once you've done that, they tend to ship a lot of vendor-specific patches and prioritise (rightly for an enterprise distro) patches that help their customers with existing codebases over collateral damage to more modern codebases. So if you're going to use it, do so with care.
FreeBSD ... does brilliantly, and will happily install very recent perls perfectly sanely. Provided you only need a single perl on the system, I'd default to getting it built via ports on FreeBSD - and keep an eye out, since the maintainer tells me he's looking into how possible multiple concurrent versions would be as well.
Manual compilation
If you just want a single perl, and you want to know exactly how it's built, doing it yourself is a completely viable option. Read the INSTALL docs, and consider the following to be your baseline:
sh Configure -Dprefix=/usr/local/perl-5.whatever -des
Also, remember to remove Policy.sh between Configure runs, because while it's very useful for reproducing things later, it can easily confuse your debugging of the build now.
perlbrew
Maximum overkill for perl5 VM and local::lib management. If you're expecting to need to test things against multiple perls and/or multiple combinations of library sets, this is a really really nice thing to have.
However, the way it provides all of the switching machinery means it introduces a bunch of extra moving parts, so while this is an excellent development tool for complex situations, I don't really like it for production deployments - "This is systems. You appear to be trying to be clever. Please stop." applies.
Happily, Perl::Build exists -
Perl::Build
This module provides a perl-build script (and there's a fatpacked version for zero-installation usage), which is basically an extracted version of the perlbrew perl building code.
If you're trying to build a single perl for deployment against, this gives you all of the "not having to think about fiddly compilation options" of perlbrew without the extra moving parts that support the perlbrew features you aren't going to use.
I am extremely glad that both perlbrew and perl-build exist, and I believe that the maintainers of both share that view.
plenv
plenv, which is distributed through github since it's written in bash, is designed to manage deployment environments. It basically works "inside out" compared to perlbrew - i.e. rather than switching between configurations while working on a single project, it expects you to have a perl configuration per project.
This is well worth a look at an all-in-one solution for deployment before you throw your own together with perl-build + carton + local::lib.
Windows
Get either Active State or Strawberry Perl, according to taste. Active State has a GUI module installer, Strawberry has a slightly better compilation toolchain, both have support for both cpan and binary packages.
It's also potentially worth looking at Cava Packager, which a number of people targeting win32 have reported great success with, but I haven't tried it myself.
-- mst, out.