To continue on the track of installing modules as a user in an administered environment, what if you want to use CPAN (you do!) then how would you go about it??

Well, first of fire away cpan:

   perl -MCPAN -e shell

If you haven’t already configured CPAN it will ask you to do it. If you have, you can reconfigure CPAN by issuing the following command at the CPAN prompt:

   o conf init

At this point the configuration will start. Where it is especially interresting for us trapped users are:

Every Makefile.PL is run by perl in a separate process. Likewise we
run 'make' and 'make install' in processes. If you have any
parameters (e.g. PREFIX, LIB, UNINST or the like) you want to pass
to the calls, please specify them here.

If you don't understand this question, just press ENTER.

Parameters for the 'perl Makefile.PL' command?
Typical frequently used settings:

    PREFIX=~/perl       non-root users (please see manual for more hints)
    
Your choice:  []

Here you would put in whatever existing directory in your home catalog. For instance:

   PREFIX=~/perllib

Or you should be able to use:

   INSTALL_BASE=~/perllib

The next interesting section is:

If you're accessing the net via proxies, you can specify them in the
CPAN configuration or via environment variables. The variable in
the $CPAN::Config takes precedence.

Your ftp_proxy? [http://www-proxy.whatevercompany.com:8080]
Your http_proxy? [http://www-proxy.whatevercompany.com:8080]
Your no_proxy?

Ok, now you should only need to finish the configuration and be ready to start installing perl modules from CPAN in your own home directory.

Remember, to use these installed modules later on you may need to add the

use lib

directive to your perl scripts or export a suitable environment variable (see previous post on the topic).

See also: Stackoverflow
See also: How do I keep my own module/library directory?

Update: Had a particularly difficult machine where CPAN persistently tried to run ‘make install’ as root, which it did not have privilage to.

This:

perl -Iperl5/lib/perl5 -MCPAN -Mlocal::lib -e 'CPAN::install(Lingua::EN::StopWords)'

Solved that problem…

See also: CPAN lib::local

Cheers!

Tags: linkedin, perl

Very often in a centrally administered organization you don’t have root access and have the possibility to install Perl modules in the ordinary system wide directory structure, here is how to build and install them locally in your own location:

% perl Makefile.PL PREFIX=<path to your local storage>

or alternatively

% perl Makefile.PL INSTALL_BASE=<path to your local storage>

% make

% make test

% make install

% make clean

To use this module later on, you can either add a:

use lib '<path to your local storage>'; 

directive in your perl scripts, or you can set some system variables:

See also: How do I add a directory to my include path (@INC) at runtime?

# syntax for sh, bash, ksh, or zsh
$ export PERLLIB=$HOME/perllib

# syntax for sh, bash, ksh, or zsh
$ export PERL5LIB=$HOME/perllib

# syntax for csh or tcsh
% setenv PERL5LIB ~/perllib

Here is what Module Build Coockbook has to say about the two alternatives (PREFIX vs. INSTALL_BASE):

prefix vs install_base

The behavior of prefix is complicated and depends on how your Perl is configured. The resulting installation locations will vary from machine to machine and even different installations of Perl on the same machine. Because of this, it’s difficult to document where prefix will place your modules.

In contrast, install_base has predictable, easy to explain installation locations. Now that Module::Build and MakeMaker both have install_base there is little reason to use prefix other than to preserve your existing installation locations. If you are starting a fresh Perl installation we encourage you to use install_base . If you have an existing installation installed via prefix , consider moving it to an installation structure matching install_base and using that instead.

Tags: linkedin, perl