The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.
 / 
local-lib-1.005000
River stage two • 34 direct dependents • 85 total dependents
92 ++
/ local::lib

NAME

local::lib - create and use a local lib/ for perl modules with PERL5LIB

SYNOPSIS

In code -

  use local::lib; # sets up a local lib at ~/perl5

  use local::lib '~/foo'; # same, but ~/foo

  # Or...
  use FindBin;
  use local::lib "$FindBin::Bin/../support";  # app-local support library

From the shell -

  # Install LWP and its missing dependencies to the 'my_lwp' directory
  perl -MCPAN -Mlocal::lib=my_lwp -e 'CPAN::install(LWP)'

  # Install LWP and *all non-core* dependencies to the 'my_lwp' directory 
  perl -MCPAN -Mlocal::lib=--self-contained,my_lwp -e 'CPAN::install(LWP)'

  # Just print out useful shell commands
  $ perl -Mlocal::lib
  export MODULEBUILDRC=/home/username/perl/.modulebuildrc
  export PERL_MM_OPT='INSTALL_BASE=/home/username/perl'
  export PERL5LIB='/home/username/perl/lib/perl5:/home/username/perl/lib/perl5/i386-linux'
  export PATH="/home/username/perl/bin:$PATH"

The bootstrapping technique

A typical way to install local::lib is using what is known as the "bootstrapping" technique. You would do this if your system administrator hasn't already installed local::lib. In this case, you'll need to install local::lib in your home directory.

1. Download and unpack the local::lib tarball from CPAN (search for "Download" on the CPAN page about local::lib). Do this as an ordinary user, not as root or administrator. Unpack the file in your home directory or in any other convenient location.

2. Run this:

  perl Makefile.PL --bootstrap

If the system asks you whether it should automatically configure as much as possible, you would typically answer yes.

3. Run this:

  make test && make install

4. Arrange for Perl to use your own packages instead of the system packages. If you are using bash, you can do this as follows:

  echo 'eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)' >>~/.bashrc

If you are using C shell, you can do this as follows:

  /bin/csh
  echo $SHELL
  /bin/csh
  perl -I$HOME/perl5/lib/perl5 -Mlocal::lib >> ~/.cshrc

You can also pass --bootstrap=~/foo to get a different location -

  perl Makefile.PL --bootstrap=~/foo
  make test && make install

  echo 'eval $(perl -I$HOME/foo/lib/perl5 -Mlocal::lib=$HOME/foo)' >>~/.bashrc

After writing your shell configuration file, be sure to re-read it to get the changed settings into your current shell's environment. Bourne shells use . ~/.bashrc for this, whereas C shells use source ~/.cshrc. Replace .bashrc or .cshrc with the name of the file you wrote above with the echo command.

If you're on a slower machine, or are operating under draconian disk space limitations, you can disable the automatic generation of manpages from POD when installing modules by using the --no-manpages argument when bootstrapping:

  perl Makefile.PL --bootstrap --no-manpages

If you want to install multiple Perl module environments, say for application development, install local::lib globally and then:

  cd ~/mydir1
  perl -Mlocal::lib=./
  eval $(perl -Mlocal::lib=./)  ### To set the environment for this shell alone
  printenv  ### You will see that ~/mydir1 is in the PERL5LIB
  perl -MCPAN -e install ...    ### whatever modules you want
  cd ../mydir2
  ... REPEAT ...

For multiple environments for multiple apps you may need to include a modified version of the use FindBin instructions in the "In code" sample above. If you did something like the above, you have a set of Perl modules at ~/mydir1/lib. If you have a script at ~/mydir1/scripts/myscript.pl, you need to tell it where to find the modules you installed for it at ~/mydir1/lib.

In ~/mydir1/scripts/myscript.pl:

  use strict;
  use warnings;
  use local::lib "$FindBin::Bin/..";  ### points to ~/mydir1 and local::lib finds lib
  use lib "$FindBin::Bin/../lib";     ### points to ~/mydir1/lib

Put this before any BEGIN { ... } blocks that require the modules you installed.

Differences when using this module under Win32

  C:\>perl -Mlocal::lib
  set MODULEBUILDRC=C:\DOCUME~1\ADMINI~1\perl5\.modulebuildrc
  set PERL_MM_OPT=INSTALL_BASE=C:\DOCUME~1\ADMINI~1\perl5
  set PERL5LIB=C:\DOCUME~1\ADMINI~1\perl5\lib\perl5;C:\DOCUME~1\ADMINI~1\perl5\lib\perl5\MSWin32-x86-multi-thread
  set PATH=C:\DOCUME~1\ADMINI~1\perl5\bin;%PATH%
  
    ### To set the environment for this shell alone
  C:\>perl -Mlocal::lib > %TEMP%\tmp.bat && %TEMP%\tmp.bat && del %TEMP%\temp.bat
  ### instead of $(perl -Mlocal::lib=./)

If you want the environment entries to persist, you'll need to add then to the Control Panel's System applet yourself at the moment.

The "~" is translated to the user's profile directory (the directory named for the user under "Documents and Settings" (Windows XP or earlier) or "Users" (Windows Vista or later) unless $ENV{HOME} exists. After that, the home directory is translated to a short name (which means the directory must exist) and the subdirectories are created.

RATIONALE

The version of a Perl package on your machine is not always the version you need. Obviously, the best thing to do would be to update to the version you need. However, you might be in a situation where you're prevented from doing this. Perhaps you don't have system administrator privileges; or perhaps you are using a package management system such as Debian, and nobody has yet gotten around to packaging up the version you need.

local::lib solves this problem by allowing you to create your own directory of Perl packages downloaded from CPAN (in a multi-user system, this would typically be within your own home directory). The existing system Perl installation is not affected; you simply invoke Perl with special options so that Perl uses the packages in your own local package directory rather than the system packages. local::lib arranges things so that your locally installed version of the Perl packages takes precedence over the system installation.

If you are using a package management system (such as Debian), you don't need to worry about Debian and CPAN stepping on each other's toes. Your local version of the packages will be written to an entirely separate directory from those installed by Debian.

DESCRIPTION

This module provides a quick, convenient way of bootstrapping a user-local Perl module library located within the user's home directory. It also constructs and prints out for the user the list of environment variables using the syntax appropriate for the user's current shell (as specified by the SHELL environment variable), suitable for directly adding to one's shell configuration file.

More generally, local::lib allows for the bootstrapping and usage of a directory containing Perl modules outside of Perl's @INC. This makes it easier to ship an application with an app-specific copy of a Perl module, or collection of modules. Useful in cases like when an upstream maintainer hasn't applied a patch to a module of theirs that you need for your application.

On import, local::lib sets the following environment variables to appropriate values:

MODULEBUILDRC
PERL_MM_OPT
PERL5LIB
PATH

PATH is appended to, rather than clobbered.

These values are then available for reference by any code after import.

CREATING A SELF-CONTAINED SET OF MODULES

You can use local::lib to prepare a directory which contains a module and all of its non-core dependencies. The --self-contained option ignores any globally installed modules when resolving dependencies, only considering modules installed in a "local::lib" directory or provided by core Perl.

A use-case for this feature would be to prepare to deploy a whole "stack" of module dependencies on a new machine, even if you have copies of the same dependencies installed globally already.

The --self-contained option should be used like this:

  # Install LWP and *all non-core* dependencies to the 'my_lwp' directory 
  perl -MCPAN -Mlocal::lib=--self-contained,my_lwp -e 'CPAN::install(LWP)'

Note that some dependencies may involve C-based "XS" code even if your target module doesn't. The issue of dealing with XS vs Pure Perl code is beyond the scope of what local::lib provides.

METHODS

ensure_directory_structure_for

Arguments: path

Attempts to create the given path, and all required parent directories. Throws an exception on failure.

Arguments: path

Prints to standard output the variables listed above, properly set to use the given path as the base directory.

setup_env_hash_for

Arguments: path

Constructs the %ENV keys for the given path, by calling build_environment_vars_for.

install_base_perl_path

Arguments: path

Returns a path describing where to install the Perl modules for this local library installation. Appends the directories lib and perl5 to the given path.

install_base_arch_path

Arguments: path

Returns a path describing where to install the architecture-specific Perl modules for this local library installation. Based on the "install_base_perl_path" method's return value, and appends the value of $Config{archname}.

install_base_bin_path

Arguments: path

Returns a path describing where to install the executable programs for this local library installation. Based on the "install_base_perl_path" method's return value, and appends the directory bin.

modulebuildrc_path

Arguments: path

Returns a path describing where to install the .modulebuildrc file, based on the given path.

resolve_empty_path

Arguments: path

Builds and returns the base path into which to set up the local module installation. Defaults to ~/perl5.

resolve_home_path

Arguments: path

Attempts to find the user's home directory. If installed, uses File::HomeDir for this purpose. If no definite answer is available, throws an exception.

resolve_relative_path

Arguments: path

Translates the given path into an absolute path.

resolve_path

Arguments: path

Calls the following in a pipeline, passing the result from the previous to the next, in an attempt to find where to configure the environment for a local library installation: "resolve_empty_path", "resolve_home_path", "resolve_relative_path". Passes the given path argument to "resolve_empty_path" which then returns a result that is passed to "resolve_home_path", which then has its result passed to "resolve_relative_path". The result of this final call is returned from "resolve_path".

A WARNING ABOUT UNINST=1

Be careful about using local::lib in combination with "make install UNINST=1". The idea of this feature is that will uninstall an old version of a module before installing a new one. However it lacks a safety check that the old version and the new version will go in the same directory. Used in combination with local::lib, you can potentially delete a globally accessible version of a module while installing the new version in a local place. Only combine "make install UNINST=1" and local::lib if you understand these possible consequences.

LIMITATIONS

Rather basic shell detection. Right now anything with csh in its name is assumed to be a C shell or something compatible, and everything else is assumed to be Bourne, except on Win32 systems. If the SHELL environment variable is not set, a Bourne-compatible shell is assumed.

Bootstrap is a hack and will use CPAN.pm for ExtUtils::MakeMaker even if you have CPANPLUS installed.

Kills any existing PERL5LIB, PERL_MM_OPT or MODULEBUILDRC.

Should probably auto-fixup CPAN config if not already done.

Patches very much welcome for any of the above.

On Win32 systems, does not have a way to write the created environment variables to the registry, so that they can persist through a reboot.

TROUBLESHOOTING

If you've configured local::lib to install CPAN modules somewhere in to your home directory, and at some point later you try to install a module with cpan -i Foo::Bar, but it fails with an error like: Warning: You do not have permissions to install into /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux at /usr/lib64/perl5/5.8.8/Foo/Bar.pm and buried within the install log is an error saying 'INSTALL_BASE' is not a known MakeMaker parameter name, then you've somehow lost your updated ExtUtils::MakeMaker module.

To remedy this situation, rerun the bootstrapping procedure documented above.

Then, run rm -r ~/.cpan/build/Foo-Bar*

Finally, re-run cpan -i Foo::Bar and it should install without problems.

ENVIRONMENT

SHELL
COMSPEC

local::lib looks at the user's SHELL environment variable when printing out commands to add to the shell configuration file.

On Win32 systems, COMSPEC is also examined.

AUTHOR

Matt S Trout <mst@shadowcat.co.uk> http://www.shadowcat.co.uk/

auto_install fixes kindly sponsored by http://www.takkle.com/

CONTRIBUTORS

Patches to correctly output commands for csh style shells, as well as some documentation additions, contributed by Christopher Nehren <apeiron@cpan.org>.

'--self-contained' feature contributed by Mark Stosberg <mark@summersault.com>.

Ability to pass '--self-contained' without a directory inspired by frew on irc.perl.org/#catalyst.

Doc patches for a custom local::lib directory contributed by Torsten Raudssus <torsten@raudssus.de>.

Hans Dieter Pearcey <hdp@cpan.org> sent in some additional tests for ensuring things will install properly, submitted a fix for the bug causing problems with writing Makefiles during bootstrapping, contributed an example program, and submitted yet another fix to ensure that local::lib can install and bootstrap properly. Many, many thanks!

pattern of Freenode IRC contributed the beginnings of the Troubleshooting section. Many thanks!

Patch to add Win32 support contributed by Curtis Jewell <csjewell@cpan.org>.

Warnings for missing PATH/PERL5LIB (as when not running interactively) silenced by a patch from Marco Emilio Poleggi.

COPYRIGHT

Copyright (c) 2007 - 2009 the local::lib "AUTHOR" and "CONTRIBUTORS" as listed above.

LICENSE

This library is free software and may be distributed under the same terms as perl itself.