cpan

There are multiple installers for cpan modules available; I know of at least CPAN.pm (comes with perl,) CPANPLUS, and cpanminus. What is the difference between the three? What situations call for using one over the other? Are there other module installers I should know about? cjm CPAN.pm ( cpan ) is the original client. It comes with Perl, so you already have it. It has the most features. It has a lot of configuration options to customize the way it works, though virtually everyone accepts the default installation. It integrates easily with local::lib . cpanminus ( cpanm ) is an attempt to

I'm tasked with replicating a production environment to create many test/sit environments. One of the things I need to do is build up Perl, with all the modules which have been installed (including internal and external modules) over the years. I could just use CPAN.pm autobundle, but this will result in the test environment having much newer versions of the external modules that production has. What is the easiest/best way to get and install (a lot of) version specific Perl modules. Make your own CPAN mirror with exactly what you want. Stratopan.com , a service, and Pinto , tools that's built

How do I tell CPAN to install all dependencies? I tried setting these in cpan : cpan> o conf prerequisites_policy follow cpan> o conf commit I still had to answer "y" a couple of times (but fewer than before it feels like). Is there a way to get it to always go ahead and install? I want to make it unattended. It would seem that I want a flag to always trust CPAN to do the right thing, and if it suggests an answer I would like to follow it (always hit Enter when it asks something). Atento Here is the one-liner making these changes permanent including automatic first-time CPAN configuration:

I have read the perldoc on modules , but I don't see a recommendation on naming a package so it won't collide with builtin or CPAN module/package names. In the past, to develop a local Session.pm module, I have created a local directory using my company's name, such as: package Company::Session; ... and Session.pm would be found in directory Company/. But I'm just not a fan of this naming convention. I would rather name the package hierarchy closer to the functionality of the code. But that's how it's done on CPAN generally... I feel like I am missing something fundamental. I also looked in

Doesn't work with other modules, but to give an example. I installed Text::CSV_XS with a CPAN setting: 'makepl_arg' => q[PREFIX=~/lib], When I try running a test.pl script: $ perl test.pl #!/usr/bin/perl use lib "/homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi"; use Text::CSV_XS; print "test"; I get Can't load '/homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Text/CSV_XS/CSV_XS.so' for module Text::CSV_XS: /homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Text/CSV_XS/CSV_XS.so: cannot open shared object file: No

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 course, not. For quite a while I would use my package manager whenever I needed to install some CPAN module to find out whether a package was available or not and to install it when it was. The obvious advantage is that you get your modules updated whenever a new version of the package becomes available. However, you get in trouble when the module is not available in pre-packaged form and there are dependencies for that module that