Can I unpack Perl dependencies to the local tree (like Ruby on Rails)?

Question

I'm integrating with some existing, "legacy" Perl code for my current project. I'm downloading some libraries via CPAN to use in a Perl script, but I would like to avoid having all the other developers/users install these libraries manually. Taking a page from my Ruby/Rails background, I thought it might be possible to "unpack" the dependencies to a local directory that's under version control and then load the libraries from there. The advantages are that (1) no one has to install specific packages manually and (2) you know everyone has the same version and can update that version easily.

I tried the easy approach and just moved the installation files to ./vendor/Perl/Pod/, ./vendor/Perl/DBD/, ./vendor/Perl/Win32/, etc and adjusted @INC accordingly. This worked fine for some libraries but not others. I would guess compiled libraries are causing problems, as well as dependencies.

Is there already a solution out there that solves this problem for me? The core of it is that I don't want to manually manage dependencies between developers or users (which we have to do now).

I'm not terribly familiar with Perl, so I apologize for my ignorance in advance.

Answer 1

I would use local::lib for this. It sets up environment variables for you, then you can install CPAN modules as normal and have them installed in a local directory.

Then just share the environment variables with the other developers.

Edit

You've commented that different users are using different operating systems. The compiled modules will need to be recompiled for each system.

I still suggest using local::lib. Combine it with a makefile for your project that will install the dependencies you need. (Assuming the Windows users use Strawberry Perl)

Answer 2

The current directory is part of the module search path. So you can put modules directly into your project's tree. The problem is that . comes last in the list of directories to search. So if another version of some module is installed on a system, you will get unexpected upgrades/downgrades. This is obviously not desirable.

Fortunately there are many ways to work around this issue. You could:

• use PAR to manage bundles of modules.
• use the lib pragma to add additional directories to the list of directories to search.
• set the PERL5LIB environment variable to alter directory search behavior.
• invoke perl with the -I option to add directories to the module search path.