Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Seeking Advice re. Managing the perl / modules installs

by Pancho (Pilgrim)
on Mar 22, 2008 at 19:10 UTC ( [id://675666]=perlquestion: print w/replies, xml ) Need Help??

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

Hello Monks,

Iím looking for advice regarding the preferred way to separate the functions of the application team from the server operations (sys admins) team when it comes to managing the perl and perl modules installs in Linux boxes.

Currently, in our prod environment, we use the Perl version that came packaged with the server, and any modules used (i.e. DBD, DBI Oracle etc) are installed by the Sys admins in a directory that they only can modify.

The Sys admins have proposed that the application team, of which I am a part, installs a version of perl and modules that we will used in our own directories and maintain that. The main reason for this being to make the programs as box independent as possible.

Another alternative I can think of is using the lib pragma to point to the modules the app team installs and point to the perl that came packaged with the box.

I like the Sys Admins suggestion because I can control the Perl version and the module installation and you are not at the mercy of whatever gets packaged with the box, but I donít have that much experience w/ Perl. Can you please advice on the pros and cons of the two alternatives above, or let me know if the Ďstandardí or typical way to resolve this is different altogether.

Thanks in advance,

  • Comment on Seeking Advice re. Managing the perl / modules installs

Replies are listed 'Best First'.
Re: Seeking Advice re. Managing the perl / modules installs
by hipowls (Curate) on Mar 22, 2008 at 20:38 UTC

    My preference is to install a separate perl for these reasons.

    • The system is never broken by an upgrade to a module. Most Linux distributions come with Perl scripts for system tasks, you don't want to maintain those.
    • You can upgrade the version of Perl without breaking the system, you don't have to track down all the modules used by the distribution scripts
    • You can install multiple versions in parallel.
    • The Perl build can be customized for your usage. Don't use threads? Don't build it.

    Whatever you choose to do, you need a process to track what CPAN modules are deployed so that you can reproduce your environment whenever you upgrade Perl or deploy to a new machine.

    You also need a process for deployment into test and production. You can't deploy an upgraded module or version of Perl whilst it is being used by the system. Personally I prefer that the sysadmins be responsible for deployment to production as we have those procedures (They involve outage windows at god awful times;)

Re: Seeking Advice re. Managing the perl / modules installs
by alpha (Scribe) on Mar 23, 2008 at 02:34 UTC
    Consider using PAR.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://675666]
Approved by Joost
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (2)
As of 2024-07-25 16:57 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.