in reply to How Do You Manage Your Perl Modules?

The Jenkins box has a minicpan that is only ever updated manually when necessary (when critical fixes arrive on CPAN or github, or when we inject our own internal modules).

Deployment for (pre-)production is done entirely through Debian packages, so we rely on prebuilt packages from the official repos, and repackage missing dependencies/newer versions.

On my dev box I have a perlbrew install, and I pull directly from public CPAN. We used to run on Etch, so I often had to downgrade my dev environment, but now we've finally switched to something more recent so we usually repackage newer versions instead of downgrading the dev environment.

The previous $client had a strict no-CPAN policy with the usual strange reasoning that "we can't trust those modules, we haven't written them", so basically we only had the core modules (from 5.8.something, no less!) + an old tarball of DBI + DateTime floating around on someone's hard drive, and no one could tell me how those got vetted (not that I was going to complain).

Comment on Re: How Do You Manage Your Perl Modules?