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?

In reply to Versions of CPAN modules for several perl scripts by szabgab

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.