local::lib(3)
π NAME π
Okay bestie, this is local::lib(3) β the manual page for local::lib. The whole point is literally: create and use a local lib/ for perl modules with PERL5LIB. That's the name, that's the vibe, that's the assignment. π
β¨
β¨ 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 '~/perl5' directory
perl -MCPAN -Mlocal::lib -e 'CPAN::install(LWP)'
# Just print out useful shell commands
$ perl -Mlocal::lib
PERL_MB_OPT='--install_base /home/username/perl5'; export PERL_MB_OPT;
PERL_MM_OPT='INSTALL_BASE=/home/username/perl5'; export PERL_MM_OPT;
PERL5LIB="/home/username/perl5/lib/perl5"; export PERL5LIB;
PATH="/home/username/perl5/bin:$PATH"; export PATH;
PERL_LOCAL_LIB_ROOT="/home/usename/perl5:$PERL_LOCAL_LIB_ROOT"; export PERL_LOCAL_LIB_ROOT;
From a .bash_profile or .bashrc file -
eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)"
π§ The bootstrapping technique π§
Okay so 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. π
Even if you do have administrative privileges, you will still want to set up your environment variables, as discussed in step 4. Without this, you would still install the modules into the system CPAN installation and also your Perl scripts will not use the lib/ path you bootstrapped with local::lib.
By default local::lib installs itself and the CPAN modules into ~/perl5.
Windows users must also see βDifferences when using this module under Win32β.
- Download and unpack the
local::libtarball from CPAN (search for"Download"on the CPAN page aboutlocal::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. - 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.
- Run this: (
local::libassumes you havemakeinstalled on your system)
make test && make install
- Now we need to setup the appropriate environment variables, so that Perl starts using our newly generated
lib/directory. If you are usingbashor any other Bourne shells, you can add this to your shell startup script this way:
echo 'eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)"' >>~/.bashrc
If you are using C shell, you can do this as follows:
% echo $SHELL
/bin/csh
$ echo 'eval `perl -I$HOME/perl5/lib/perl5 -Mlocal::lib`' >> ~/.cshrc
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.
π¦ Bootstrapping into an alternate directory π¦
In order to install local::lib into a directory other than the default, you need to specify the name of the directory when you call bootstrap. Then, when setting up the environment variables, both perl and local::lib must be told the location of the bootstrap directory. The setup process would look as follows:
perl Makefile.PL --bootstrap=~/foo
make test && make install
echo 'eval "$(perl -I$HOME/foo/lib/perl5 -Mlocal::lib=$HOME/foo)"' >>~/.bashrc
. ~/.bashrc
πΈ Other bootstrapping options πΈ
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
To avoid doing several bootstrap for several Perl module environments on the same account, for example if you use it for several different deployed applications independently, you can use one bootstrapped local::lib installation to install modules in different directories directly this way:
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 ...
If you use .bashrc to activate a local::lib automatically, the local::lib will be re-enabled in any sub-shells used, overriding adjustments you may have made in the parent shell. To avoid this, you can initialize the local::lib in .bash_profile rather than .bashrc, or protect the local::lib invocation with a $SHLVL check:
[ $SHLVL -eq 1 ] && eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)"
If you are working with several "local::lib" environments, you may want to remove some of them from the current environment without disturbing the others. You can deactivate one environment like this (using bourne sh):
eval $(perl -Mlocal::lib=--deactivate,~/path)
which will generate and run the commands needed to remove "~/path" from your various search paths. Whichever environment was activated most recently will remain the target for module installations. That is, if you activate "~/path_A" and then you activate "~/path_B", new modules you install will go in "~/path_B". If you deactivate "~/path_B" then modules will be installed into "~/pathA" -- but if you deactivate "~/path_A" then they will still be installed in "~/pathB" because pathB was activated later.
You can also ask "local::lib" to clean itself completely out of the current shell's environment with the "--deactivate-all" option. 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 π»
To set up the proper environment variables for your current session of "CMD.exe", you can use this:
C:\>perl -Mlocal::lib
set PERL_MB_OPT=--install_base C:\DOCUME~1\ADMINI~1\perl5
set PERL_MM_OPT=INSTALL_BASE=C:\DOCUME~1\ADMINI~1\perl5
set PERL5LIB=C:\DOCUME~1\ADMINI~1\perl5\lib\perl5
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%\tmp.bat
### instead of $(perl -Mlocal::lib=./)
If you want the environment entries to persist, you'll need to add them to the Control Panel's System applet yourself or use App::local::lib::Win32Helper.
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.
πͺ PowerShell πͺ
local::lib also supports PowerShell, and can be used with the "Invoke-Expression" cmdlet.
Invoke-Expression "$(perl -Mlocal::lib)"
π 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:
PERL_MB_OPTPERL_MM_OPTPERL5LIBPATHPERL_LOCAL_LIB_ROOT
When possible, these will be appended to instead of overwritten entirely.
These values are then available for reference by any code after import. β¨
π CREATING A SELF-CONTAINED SET OF MODULES π
See lib::core::only for one way to do this - but note that there are a number of caveats, and the best approach is always to perform a build against a clean perl (i.e. site and vendor as close to empty as possible). π
π IMPORT OPTIONS π
okay so bestie, these are the little extra values you can pass to the local::lib import besides the directory you wanna use. They go in like:
use local::lib '--option'[, path];
or:
perl -Mlocal::lib=--option[,path]
--deactivateβ removes the chosen path (or the default path) from the module search paths iflocal::libadded it, instead of adding it. lowkey the undo button.--deactivate-allβ removes all directories thatlocal::libadded to search paths from the search paths. full reset energy.--quietβ donβt output any messages about directories being created. shhh, no commentary.--alwaysβ always add directories to environment variables, ignoring whether theyβre already included. no vibe check, just add βem.--shelltypeβ specifies the shell type to use for output. by default, the shell is detected based on the environment. should be one of:bourne,csh,cmd, orpowershell. pick your fighter.--no-createβ preventslocal::libfrom creating directories when activating dirs. > β οΈ this is likely to cause issues on Win32 systems. bestie, be careful.
π§ CLASS METHODS π§
πΈ ensure_dir_structure_for πΈ
- Arguments:
$path - Return value: None
attempts to create a local::lib directory, including subdirectories and all required parent directories. throws an exception on failure. itβs giving βbuild the whole nest, not just one twig.β
πΈ print_environment_vars_for πΈ
- Arguments:
$path - Return value: None
prints to standard output the variables listed above, properly set to use the given path as the base directory. very βhereβs the receipts, printed.β
πΈ build_environment_vars_for πΈ
- Arguments:
$path - Return value:
%environment_vars
returns a hash with the variables listed above, properly set to use the given path as the base directory. same info as above, but as a hash instead of printed output.
πΈ setup_env_hash_for πΈ
- Arguments:
$path - Return value: None
constructs the %ENV keys for the given path, by calling build_environment_vars_for. the middle-step bestie.
πΈ active_paths πΈ
- Arguments: None
- Return value:
@paths
returns a list of active local::lib paths, according to the PERL_LOCAL_LIB_ROOT environment variable and verified against what is really in @INC. no fake paths allowed.
πΈ install_base_perl_path πΈ
- Arguments:
$path - Return value:
$install_base_perl_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.
πΈ lib_paths_for πΈ
- Arguments:
$path - Return value:
@lib_paths
returns the list of paths perl will search for libraries, given a base path. this includes the base path itself, the architecture specific subdirectory, and perl version specific subdirectories. these paths may not all exist. itβs giving βpotential paths, not guaranteed real estate.β
πΈ install_base_bin_path πΈ
- Arguments:
$path - Return value:
$install_base_bin_path
returns a path describing where to install the executable programs for this local library installation. appends the directory bin to the given path.
πΈ installer_options_for πΈ
- Arguments:
$path - Return value:
%installer_env_vars
returns a hash of environment variables that should be set to cause installation into the given path. set these and the installer knows where to go.
πΈ resolve_empty_path πΈ
- Arguments:
$path - Return value:
$base_path
builds and returns the base path into which to set up the local module installation. defaults to ~/perl5. if you donβt pick a spot, it picks the classic one.
πΈ resolve_home_path πΈ
- Arguments:
$path - Return value:
$home_path
attempts to find the userβs home directory. if no definite answer is available, throws an exception. it does not guess. it refuses to be messy.
πΈ resolve_relative_path πΈ
- Arguments:
$path - Return value:
$absolute_path
translates the given path into an absolute path. no relative-path nonsense left behind.
πΈ resolve_path πΈ
- Arguments:
$path - Return value:
$absolute_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. itβs a little relay race, and every step matters.
π¦ OBJECT INTERFACE π¦
π new π
- Arguments:
%attributes - Return value:
$local_lib
constructs a new local::lib object, representing the current state of @INC and the relevant environment variables. main character object energy, honestly.
π ATTRIBUTES π
rootsβ an arrayref representing activelocal::libdirectories.incβ an arrayref representing@INC.libsβ an arrayref representing thePERL5LIBenvironment variable.binsβ an arrayref representing thePATHenvironment variable.extraβ a hashref of extra environment variables (e.g.PERL_MM_OPTandPERL_MB_OPT).no_createβ if set,local::libwill not try to create directories when activating them.
π OBJECT METHODS π
π¦ clone π¦
- Arguments:
%attributes - Return value:
$local_lib
constructs a new local::lib object based on the existing one, overriding the specified attributes. copy/paste, but make it intentional.
π¦ activate π¦
- Arguments:
$path - Return value:
$new_local_lib
constructs a new instance with the specified path active. weβre turning it on, bestie.
π¦ deactivate π¦
- Arguments:
$path - Return value:
$new_local_lib
constructs a new instance with the specified path deactivated. respectfully turning it off.
π¦ deactivate_all π¦
- Arguments: None
- Return value:
$new_local_lib
constructs a new instance with all local::lib directories deactivated. every local::lib path? gone. all of βem.
π¦ environment_vars_string π¦
- Arguments:
[ $shelltype ] - Return value:
$shell_env_string
returns a string to set up the local::lib, meant to be run by a shell. itβs the βpaste this into your shell configβ string.
π¦ build_environment_vars π¦
- Arguments: None
- Return value:
%environment_vars
returns a hash with the variables listed above, properly set to use the given path as the base directory. yes, it says βgiven pathβ even though thereβs no argument listed here β thatβs the original wording, bestie, iβm not gonna invent lore.
π¦ setup_env_hash π¦
- Arguments: None
- Return value: None
constructs the %ENV keys for the given path, by calling build_environment_vars. env hash setup, no printing, just doing the thing.
π¦ setup_local_lib π¦
constructs the %ENV hash using setup_env_hash, and set up @INC. thatβs the whole move: env hash first, then @INC gets its little update.
β οΈ A WARNING ABOUT UNINST=1 β οΈ
bestie, pause. be careful about usinglocal::libin combination withmake 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 withlocal::lib, you can potentially delete a globally accessible version of a module while installing the new version in a local place. only combinemake install UNINST=1andlocal::libif you understand these possible consequences. no cap, this is a βread the whole warningβ situation.
π LIMITATIONS π
- Directory names with spaces in them are not well supported by the perl toolchain and the programs it uses. pure-perl distributions should support spaces, but problems are more likely with dists that require compilation. a workaround you can do is moving your
local::libto a directory with spaces after you installed all modules inside yourlocal::libbootstrap. but be aware that you canβt update or install CPAN modules after the move. itβs giving βspaces are cute until the toolchain gets weird.β - Rather basic shell detection. right now anything with
cshin 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 theSHELLenvironment variable is not set, a Bourne-compatible shell is assumed. - Kills any existing
PERL_MM_OPTorPERL_MB_OPT. not βadjusts,β not βgently nudgesβ β kills. - Should probably auto-fixup CPAN config if not already done. βshould probablyβ is doing a lot of work there, but thatβs what it says.
- On VMS and MacOS Classic (pre-OS X),
local::libloadsFile::Spec. this means anyFile::Specversion installed in thelocal::libwill be ignored by scripts usinglocal::lib. a workaround for this is usinguse lib "$local_lib/lib/perl5";instead of usinglocal::libdirectly. - Conflicts with ExtUtils::MakeMakerβs
PREFIXoption.local::libuses theINSTALL_BASEoption, as it has more predictable and sane behavior. if something attempts to use thePREFIXoption when running aMakefile.PL, ExtUtils::MakeMaker will refuse to run, as the two options conflict. this can be worked around by temporarily unsetting thePERL_MM_OPTenvironment variable. - Conflicts with Module::Buildβs
--prefixoption. similar to the previous limitation, but any--prefixoption specified will be ignored. this can be worked around by temporarily unsetting thePERL_MB_OPTenvironment variable.
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. so yeah, reboot persistence is not happening there.
π§ TROUBLESHOOTING π§
so say youβve configured local::lib to install CPAN modules somewhere into 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. yikes.
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. slay. we fixed it.
π ENVIRONMENT π
SHELLCOMSPEC
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.
π SEE ALSO π
- Perl Advent article, 2011 β
http://perladvent.org/2011/2011-12-01.html
π«Ά SUPPORT π«Ά
IRC: join #toolchain on irc.perl.org.
β¨ AUTHOR β¨
Matt S Trout <mst@shadowcat.co.uk> http://www.shadowcat.co.uk/
auto_install fixes kindly sponsored by http://www.takkle.com/
π CONTRIBUTORS π
Okay so this whole thing is a group project and honestly? The group chat ATE. Every single one of these people showed up and left the codebase better than they found it, so let's give them their flowers fr fr.
- Christopher Nehren
<apeiron@cpan.org>β sent in patches so the commands get output correctly for csh style shells, plus some documentation additions. king behavior π - Torsten Raudssus
<torsten@raudssus.de>β doc patches for a custom local::lib directory, more cleanups in the english documentation, AND a german documentation. multilingual icon β¨ - 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! π
- Curtis Jewell
<csjewell@cpan.org>β patch to add Win32 support. windows besties, this one's for you πͺ - Marco Emilio Poleggi β warnings for missing
PATH/PERL5LIB(as when not running interactively) silenced by a patch from him. ty for the quiet π - Mark Stosberg
<mark@summersault.com>β provided the code for the now deleted--self-containedoption. gone but not forgotten ποΈ - David Mertens
<dcmertens.perl@gmail.com>(run4flat) β documentation patches to make win32 usage clearer. clarity slay β¨ - Breno G. de Oliveira
<garu@cpan.org>β Brazilian portuguese translation and minor doc patches contributed by him. π - Andrew Rodland
<arodland@cpan.org>β improvements to stacking multiple local::lib dirs and removing them from the environment later on. stacking goated π - Hakim Cassimally
<osfameron@cpan.org>β patch for Carp version mismatch. π₯ - Graham Knop
<haarg@haarg.org>β rewrite of internals and numerous bug fixes and added features. the internals glow-up, no cap πβ¨
π COPYRIGHT π
Copyright (c) 2007 - 2013 the local::lib "AUTHOR" and "CONTRIBUTORS" as listed above. So like, all the names you just scrolled through β yeah, them π
π LICENSE π
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself. go wild bestie, it's literally yours π¦
and that's the whole page!! you made it to the end, i'm so proud of you π₯Ήπ go forth and local::lib responsibly, and remember: if it's in your environment, it's in your heart π«Ά
Ok bye!! This was local::lib(3) from perl v5.42.0, dated 2023-08-07 β mwah, drink some water, and see you in the next manpage π
πΈπ
π¦ where this page comes from
- opensuse-leap 16.0: perl-local-lib 2.000029-bp160.1.11 Β· Artistic-1.0 OR GPL-1.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms