How do YOU manage Perl modules when using a package manager?

Question

A recent question here on SO got me thinking.

On most Linux distributions that I tried, some Perl modules would be available through the package manager. Others, of

Answer 1

I recommend use only cpan. The modules includes in Linux distro is only to cover package dependency. When you are installing linux without internet access with only CDs, it can't use cpan, so some modules are included as packages, but to a Perl developer this is bad.

Also I used to have a cpan configured to install modules in my home, (.perl) without root login needed.

Answer 2

I also use the cpan shell and local::lib.

You shouldn't need a Task:: for each project. Just use Module::Install (I like to use Module::Starter like this:

$ module-starter --mi --module=Module::Name --author="Me" --email=me@cpan.org

and then just pop your dependencies in requires 'module::dependency'; in the Makefile.PL. Finally when it's install time, you just perl Makefile.PL (answer yes) then make installdeps

[edit 5 years on from when I gave this answer originally]

These days perlbrew and cpanm are the things to use. local::lib still has a use-case, but the combination of perlbrew and cpanm solve a superset of those cases. Use local::lib when you're not prepared to compile your own perl.

Answer 3

I am using Debian for development, and production, and rely on debian Perl packages that are provided with the distro.

For cases where I need a Perl module that is not available in debian, I usually create my own debian package of it and install it.

Ofcourse, this method is not without faults, as a a lot of debian perl modules are outdated (at least in the current debian stable version - etch), and backporting something like Catalyst which has lots of dependencies is not practical.

However, by relying on the OS package manager, I retain all the great features of it, which bring easy maintenance, especially for deployed servers, as you know exactly what packages are installed, and a simple apt-get update;apt-get upgrade (from debian, or from a local repository) upgrades all servers to the same state, including the Perl modules.

Answer 4

For production:

In development, choose a version of the perl module which seems right for the requirements; if possible choose the target OS's shipped version (this makes most of the following superfluous), otherwise, pick another one. Create a RPM spec file for it. Use the clean build VM to build the RPM in a reproducable way (from a specfile / source checked in on the appropriate branch).

When the final build can be built (after merge), do the same build from the release branch, commit generated RPMs into deployment repository. This will be used in final validation and then released to production by being copied to the production repository.

All servers in production use the exact same binary that has been fully tested; they use the same spec file and source as the developer intended.

Perl modules are NOT upgraded by any process which does not follow this model. Nor is any other production software.

Answer 5

We install everything via the CPAN shell. This does ignore what package managers have to offer, but it avoids the headaches you mention when trying to work with them (firing for dependencies, using correct versions).

In addition, it means that our packages can be built programatically (or manually via the shell) on any platform where CPAN runs. Having a dependency on a package manager would affect your ability to distribute your software to platforms that don't use/support that package manager.

Answer 6

Since this question was originally asked, perlbrew has been released. It makes installing custom, self-contained perl installs trivial. And switching between those versions is just as easy:

perlbrew switch $version