Versions of CPAN modules for several perl scripts

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

At a client we gave hundresds of scripts that were developed during the years.
Some of them are simple onces with no module dependency others use several CPAN modules.
Some of the scripts come with the CPAN modules they need so I know with which version of the modules those scripts use, others have just use XYZ; in their code and I don't know if they have any version restictions.
I already noticed that I have several scripts coming with different versions of the same module.
Some scripts use PAR for distributing modules, others require you to install them by yourself to @INC.

The local legal department decied that they want to check and approve or reject each module before we can use them, so I collect the names and versions of the module we need.

I am looking for a strategy to consolidate this mess so we won't go crazy in maintaining the scripts and the required CPAN modules and legal won't need to approve 3-4 version of the same CPAN module. I thought of several strategies:

One central CPAN installation
We install all the CPAN modules in @INC, all the scripts use this installation.

For this we pick one version from each module - probably the newest among those I saw in use or even the latest from CPAN - get legal to approve it and make sure all the scripts work with this version.

Every script needs to use these versions and only in very special cases we accept the use of another version of a module. In this case we need to supply the module in perllib directory private to that script.

This approach reduces the duplication in module installations but makes it quite difficult or impossible to upgrade a CPAN module as we have to make sure that all the scripts work properly with the new version.

Each script comes with its own perllib directory
Every script author manages the list of his own CPAN modules and versions.
This way noone is foced to look at what others are doing in terms of CPAN versions.

The problem arises if we have a common library using some CPAN modules and a script that is using CPAN modules and this library. If they use different version of the same CPAN module or if the library is upgrading it CPAN module we are back in the same problem as with "one CPAN installation". If we handled this internal library the same way as we do with the CPAN modules then every script author can decide when to upgrade to the new version and deal with the version collision then.

The problem of course is that we have many duplicate installations of the same modules and I am sure we will soon have different versions of the same modules.

We also need to have an easy way to install these CPAN modules on the production systems.

Separate perllib for each CPAN module
In this case we install every cpan module in a directory of its own:
perllib/dbi_1.49
perllib/dbi_1.50
each script can then "use lib" whatever directories it wants and will get exactly the module versions it needs. This might make module installation easier as we can ask the system group to install each module, but we might break interdependencies easily. E.g. DBD::SQLite might depend on DBI::1:50 and during the installation of DBD::SQLite we might have used perllib/dbi_1.50 but there is nothing to stop us from trying to use it now with perllib/dbi_1.49.

This does not sound like a good idea, after all.

What strategies are you following?

Comment on Versions of CPAN modules for several perl scripts

Replies are listed 'Best First'.
Re: Versions of CPAN modules for several perl scripts by Fletch (Bishop) on May 16, 2006 at 13:51 UTC
The first thing we do, let's kill all the lawyers. -- Henry VI (Part 2) TMTOWTDI . . . :) In all seriousness though . . . bleh. You might could use Envy to manage `PERL5LIB` with things going into separate destination directories. Each module (or maybe a collection of modules and it's prereqs; e.g. DBI and whatever DBD you're using) would be set up as a dimension in Envy and then your Perl gets run by shell wrappers which `envy load DBI_1_50` etc the correct versions. Granted it's not optimal, but then neither is your situation. This might at least help manage it.	[reply]
Re: Versions of CPAN modules for several perl scripts by jdtoronto (Prior) on May 16, 2006 at 14:17 UTC
I have a somewhat similar situation where I deliver tools written in Perl into an IBM environment where the client does not want to know about Perl. So we have chosen to use PerlApp from ActiveState, but an equally valid choice would be PAR. This way we can precisely control what is deployed - but all of the dependency testing is kept at the development end which is where I think it ought to be. We also have some Windows Perl/Tk applications. It is even more important there because you can readily find dll's on many Windows installations that are not usuable. In one case we have to go so far as to specifically remove two SSL related encryption dll's fomr teh system directory. PerlApp has been our friend here too. We can precisely control the Perl environment and I am sure that PAR would do the same. The legal situation is interesting and we run into this with the IBM user - which is a major corporation. Using a packager we can go through the legal issues at development and maintain the tracking necessary for standards compliance without leaving ourselves open to any risk of changes at the production level. jdtoronto	[reply]
Re: Versions of CPAN modules for several perl scripts by chromatic (Archbishop) on May 16, 2006 at 16:48 UTC
Ask your legal department to approve or reject specific licenses. If you get approval for the Perl license, suggest that it implicitly covers most CPAN modules you will ever use.	[reply]
Re^2: Versions of CPAN modules for several perl scripts by szabgab (Priest) on May 16, 2006 at 21:03 UTC
That is a good idea and I'll check that but this is a large international company, (that bought my client) and I think they want to approve every single CPAN module/version separately. If I am not mistaken, in addition to reading the license they might scan the source code as well to make sure it does not have dangerous material in it.	[reply]