My favorite pitfall: setting up CPAN

[sundialsvc4]

My personal favorite “pitfall of Perl” is how to set up CPAN when you are starting on new projects on a new computer, or in a new login-account (say, project specific) on an existing machine.   Here’s a quick summary of my lessons-learned, offered as pragmatic wisdom and meant to be “correct enough,” to wit:

Start by searching here for “Perl as a non-root user.”   Make sure that you are prepared ... knowing how the cpan command works and what things like o conf do in that context; knowing what @INC means, and what things like the PERL5LIB environment variable do; issuing the perl -V command (with a capital “V”) and knowing the implications of what you see there.   If not, do your research first.   You will have yourself to thank, and many hair follicles will be saved.   (At my age, anyhow, they’re precious indeed.)

Choose the location of your personal private CPAN repository, allocate the directory and make sure that you have access to it without being root.   Set the PERL5LIB variable properly to refer to it now, in the proper manner for Linux/Unix vs. Windows, such that this environment variable setting will always be re-established at login and that it is also in place right now before you proceed further.   perl -V should reflect your change; see that it does.

If you don’t do this, subsequent module installations won’t seem to “stick,” or prerequisites just-installed(!) won’t appear to be installed at all ... because Perl is not looking for modules in the places where it is installing modules!   Perl uses your o conf setting to establish build-locations, but PERL5LIB to determine where to search for modules, yes, even while the cpan command is running.   So you must be certain that the desired setting will be established at login a-n-d that it is in effect right now! (Oooh, ouch, how badly that one has bit me!)

There are two different ways to build modules in Perl.   Both of them are referred-to in CPAN and both of them ought to be configured because you just can’t be 100% sure which one a particular module might try to use.   The most important settings will be ones that cause modules to be installed into your CPAN repository instead of the system-provided one.

CPAN will offer to guess the proper settings for you.   While it’s okay to let it run through those initially, then go back and review every one of the settings because many of them will require changes.

I always think that it’s a good idea to set up your own private CPAN for any project, and to do so “per project” so that whatever you do for Client-X does not affect what you are doing for Client-Y.   And, never modify anything that the system might provide, except by using whatever “package” installation mechanism your system uses.   Many system maintenance tools are built in Perl, and you really don’t want to do anything to jeopardize them.   For the same reason, you may or may not want to modify global definitions of PERL5LIB or introduce global definitions of your own, i.e. that might be “seen” by the user that is responsible for running maintenance commands.   (At the very least, you need to be fully aware of what is going on, when you run those commands.)   Sometimes that software takes matters into its own hands with a use lib statement, but sometimes it may not.   There may be no negative side effects, or there may be.

... anyone else chime in?

[moritz]

I go one step farther and always leave the system Perl alone entirely, except for bootstrapping App::perlbrew. That and App::cpanminus (installable with perlbrew install-cpanm) make installing perl modules really easy and pleasant.

Previously I used local::lib to manage local module installation from CPAN, but I found that some modules need newer versions of core modules, and often that need conflicts with the system perl.

[Arunbear]

I'm also a happy cpanminus user:

+% cpanm -n Attempt
!
! Can't write to /usr/local/share/perl5 and /usr/local/bin: Installing
+ modules to /home/arun/perl5
! To turn off this warning, you have to do one of the following:
!   - run me as a root or with --sudo option (to install to /usr/local
+/share/perl5 and /usr/local/bin)
|   - run me with --local-lib option e.g. cpanm --local-lib=~/perl5
!   - Set PERL_CPANM_OPT="--local-lib=~/perl5" environment variable (i
+n your shell rc file)
!   - Configure local::lib in your shell to set PERL_MM_OPT etc.
!
--> Working on Attempt
Fetching http://search.cpan.org/CPAN/authors/id/M/MA/MARKF/Attempt-1.0
+1.tar.gz ... OK
Configuring Attempt-1.01 ... OK
Building Attempt-1.01 ... OK
Successfully installed Attempt-1.01
1 distribution installed

It makes installing modules quick and easy, and doesn't need to run as root. Another bonus is that it can be installed as a standalone script without needing to use cpan.

[zwon]

It's a long time since I had to configure cpan (well, I did it today when I ran dh-make-perl for the first time on a new machine, but it doesn't count). Usually for system perl I just use packages from the repository, or build packages with dh-make-perl if the repository doesn't have what I need. For perlbrewed perls I don't have to care about locations, so I just use cpanm without any configuration. Perlbrew may also help with Client-X/Y thing, you can just install new perl for every project, thought I don't have such a problem.

[Anonymous Monk]

perl -I/home/user/stuff/lib/perl5 -S myfoobar.pl
perl -Mlib=/home/user/stuff/lib/perl5 -S perlcritic

export PERLLIB=/home/user/stuff/lib/perl5
myfoobar.pl

export PERL_MM_USE_DEFAULT=1
export PERL_MB_OPT=--install_base /home/user/stuff
export PERL_MM_OPT=INSTALL_BASE=/home/user/stuff
export AUTOMATED_TESTING=0

cpan -fi Module Module Module Module Module Module

cpanp -i Module Module Module --allow_build_interactivity=0 --skiptest=0 --force --prereqs=1 --no_update=1

[Aldebaran]

thanks for your post, sundial, it inspired me to take another wack at shaking the bugs out of my CPAN set-up, which, now, seems to work just fine

I hadn't been able to download a module I wanted, but now after I did

sudo perl -MCPAN -e shell
install CPAN
reload CPAN

, it seems to be alright again. A person like me might spend months away from this linux partition before being able to address it again, so sometimes I can't remember what all I've done, what is still buggy, what modules I have, etc.