I'll be hosting an open discussion on this tomorrow at the Los Angeles Perl Mongers meeting tomorrow. (Wed 2009-09-23). Let's see what we can dig up.
I've been at a few perl companies now, and they all seem to have taken different approaches. Yes,
TIMTOWTFIU. This seem like it should already be a "solved problem," so what are the best practices in this arena?
Popular memes in this space:
- System Perl
- Install to system perl via cpan. Upgrade whenever.
- Install to system perl via package manager, deb or rpm. Manually roll unpackaged cpan modules through a tool like cpanflute.
- Sub part 1: install those rpms/dpkgs manually
- Sub part 2: run a local yum/apt-get/dag repository internally to pull "trusted" internally packaged cpan modules
- Install via system tools (puppet, etc) live on each box from a configuration file of needed modules.
- (shared) Application Perl, compile your own single perl version for internal applications
- Install into the application perl via cpan
- check into local source control source for third party modules, install during application install.
- check into local source control binary version of third party modules.
- Install into local library, using Local::Lib with either application or system perl.
- Install from a "mini cpan", maintained internally and populated with vetted, approved third party modules.
If you're just installing a handful of modules, the ad-hoc approach may be sufficient. Right now I'm writing some new apps with Moose, and installing that module dependency chain seems crazy without figuring out a plan. With Moose and the MooseX namespace there are probably 20+ modules I want to install, and many of them are improving and releasing rapidly. Edit: Sorry Dave, you're right, not hundreds of modules. I didn't mean to spread Moose FUD, I love the Moose
Plan: flesh out this page with links to the current wisdom on these matters, from fellow iron mongers, perl monks, etc. I know I've ready half a dozen recent articles on this, time to find and organize them.