What concerns should I have when installing additional Perl modules on a server?

Question

I would like to ask my system administrator to install various Perl modules such as Moose and Data::Alias. The system is Red Hat Enterprise Linux 5, running Perl 5.8.8. The only problem that I can think of is that some already-installed modules might need to be upgraded and thus run the risk of breaking something. What else should I be concerned about?

Answer 1

I do not know your company's policy, but it would probably be a better idea not to mess with your system perl and install the additional libraries and their prerequisites (and even a dedicated perl) in a different location and use lib.

See also How do I keep my own module/library directory? in perlfaq.

Answer 2

Our systems administrators are the ones who are concerned with making sure requested Perl modules don't break anything else on their systems.

So we ask, then they can say "No, that will break X, please install that in user-space." or "We'll install that at non-standard location Y, for compatibility reasons." I don't know all of the things they take into consideration when making that decision. The only thing I am supposed to know is whether or not my applications will break when modules are installed/updated.

If your system administrators are passing this responsibility (i.e. knowing the impact on the system as a whole) to you as a developer, it's probably much safer to go along with Sinan's suggestion and install the modules you need in a non-standard location for yourself. Having to be a system administrator and a developer at the same time while being paid to be only one is no fun.

Answer 3

This is an often asked question especially if you are using shared hosting or have a hosting provider that is leery of installing perl modules.

There is a fix, a way to work around this problem of mixing system modules and your own modules, and that fix is called local::lib. local::lib provides a way for you to install modules locally, in a library specified by you, which you have control over. You can use /home/you/perl5/ for example, or any path you think will work.

PS - Moose modules will most likely not interfere with other perl 5 modules since Moose has clean and separate namespace. It does require lots of modules from CPAN however, so warn your sysadmin in advance. :)

Also, ask your sysadmin to upgrade perl to 5.10, that brings lots of good new stuff into perl's core and allows you to use some shiny new perl technology.

Answer 4

The trick is to not get rid of your old setup until you know your new setup works. The rub is that the CPAN toolchain doesn't care and will happily install new files over old ones without giving you a way to uninstall your damage.

If I'm working on a big project where I'm going to upgrade modules, I like to put the new modules in their own, new directory. I can test things by settingPERL5LIB to the new directories, and if it doesn't work out, I'm back to the old setup with a simple change of the environment.

Some people do something similar with source control. They put their modules directory in a versioning system. When they install new modules, they check in the source. When something breaks, they just roll back the changes. They can also tag versions so they can roll back to any working point.