Managing modules of various versions

TomDLux has asked for the wisdom of the Perl Monks concerning the following question:

In my new position we have a large set of code to manage. Most of it is Perl 5.12, using a set of modules which must be getting out of date.

That's not necessarily a big concern now, they do their job. But when we need new features, at some point, we want to be able to install new versions of modules while keeping the old versions around. Existing code can run old versions, until they need to be updated for some other reason, then they can be updated and tested.

The alternative is to modify and test an overwhelming amount of code at the same time, or else to risk upgrading all the programs at once, without individual testing. Don't like either of those alternatives.

I see Ingy wote a module 'only' back in 2005 ...

use only Class::Date => '1.1.8-1.1.10';
[download]

Is that the best system to use? or are there alternatives?

As Occam said: Entia non sunt multiplicanda praeter necessitatem.

Comment on Managing modules of various versions Download Code

Replies are listed 'Best First'.
Re: Managing modules of various versions by flexvault (Monsignor) on Feb 20, 2013 at 11:39 UTC
Hello TomDLux, You don't say what operating systems you are using, but if it's a nix version, you should be able to use 'ln -s'. I support a number of nix ( AIX, Debian, Suse, etc ) boxes and I leave the default Perl to the operating system. But I install different versions of Perl in the '/usr/local/bin/' directory. I use a separate filesystem (or directory) for all Perl version source code and 'configure' and 'make' etc so that I have completely different directories for each Perl version. I then go to the '/usr/local/bin/' directory and move the newly installed 'perl' to 'perl5.14.2' or whatever the actual version is. Now if it's a new and untested Perl, I use link 'ln -s -f perl5.14.2 perltest'. You need the force if it is already defined. When the testing is complete and your happy with the Perl version, you use link 'ln -s -f perl5.14.2 perlgood' and now your "official" version on that box is 'perlgood'. ( Note: I don't use 'perlgood', but link the base 'perl' to the tested 'good' version) (Also, any CPAN dependencies have to be installed in the new Perl.) You can verify which release by: `perltest -v` [download] And you can see all versions you have by: `ls -l /usr/local/bin/perl` [download] and you get something like this:(just the end column) `... /usr/local/bin/perl -> perl5.12.2 ... /usr/local/bin/perl5.10.1.threads ... /usr/local/bin/perl5.10.1 ... /usr/local/bin/perl5.12.2 ... /usr/local/bin/perl5.16.0 ... ... /usr/local/bin/perltest -> perl5.16.0` [download] Okay, so how does this help you? Now you have a way to check-point scripts that have a dependency that a newer version of Perl doesn't work/support/etc. For instance you notice that I have a threaded and non-threaded versions of perl5.10.1. If you have a script dependency on threads, you can hard-code the shebang to: `#!/usr/local/bin/perl5.10.1.threads -w` [download] Unless I have a need for 'threads' in nix, I run all scripts with a non-threaded Perl for perfomance. YMMV! AIX and CPAN are almost mutually exclusive. So I usually have to download and manually install. So scripts on AIX tend to not get updated as much as the Linux systems. I hope you get the idea, and if you improve the process I'd be interested in any and all improvements. ( And don't forget to document the process for your fellow workers. ) Good Luck...Ed "Well done is better than well said." - Benjamin Franklin	[reply] [d/l] [select]
Re: Managing modules of various versions by tobyink (Canon) on Feb 20, 2013 at 09:48 UTC
Go and read Santa has Dependencies Too! `package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name`	[reply]
Re: Managing modules of various versions by Anonymous Monk on Feb 20, 2013 at 03:42 UTC
Is that the best system to use? or are there alternatives? That is probably the simplest out of the box by a hair , but all they all do is manage @INC and INSTALL_BASE, and you can manage it yourself the same, as trivially or as complicated as you want	[reply]


XP is just a number
	PerlMonks