On Mon, Jul 22, 2013 at 09:39:33PM +0100, Dirk Koopman wrote: > And yes, I > would advise against producing production code that has lots of external > (CPAN) dependencies, especially if the normal path through those modules > touches most of them. There are numerous (horror) stories of what can > happen when one wants to update something, say a perl or a major CPAN > component with many dependencies.
But you have this problem in any language, not just perl. I'm happy to use loads of stuff from the CPAN, but not to use it straight from the CPAN. Ideally, you'll build your own packages from your CPAN dependencies (deb, rpm or whatever), as well as building a package for your application that depends on them all. That way you stay in control and can be sure that all your machines have the same version of everything. If you do that it's a good idea to keep those packages, including the package that contains your build of perl, reasonably up-to-date. This will minimise the pain of upgrading (you'll just have to deal with occasional small incompatibilities instead of a many-tentacled horror) and you'll also have a procedure right from the start for dealing with upgrades, so when you actually *need* to upgrade it won't be so fraught with peril. As an alternative to building your own packages, use a CPAN mirror that doesn't randomly change, such as http://cp2013-06an.barnyard.co.uk/ which is the CPAN as it was at 2013-06-01Z00:00:00. Then every so often change to using a later snapshot in dev and when it's all working again use that later snapshot in your other environments. Of course, if you go this way you'll probably want to have separate dev and maint environments for your programmers. But that's OK, any machine built in the last five years can run multiple virtual machines. -- David Cantrell | Reality Engineer, Ministry of Information I remember when computers were frustrating because they did exactly what you told them to. That seems kinda quaint now. -- JD Baldwin, in the Monastery