• SYNOPSIS
  • Differences when using this module under Win32
• IMPORT OPTIONS
• CLASS METHODS
• OBJECT INTERFACE
• ATTRIBUTES
• OBJECT METHODS

• Download Perl Module
• Perl Module File

Xcode can also be installed through the Mac App Store. (Note: in 10.3 you should also install the optional BSD SDK, otherwise installing new Perl modules won't work.) Last updated: 2014-01-04.

1. The #1 Perl solution used by enterprises. Save time and stop worrying about support, security and license compliance. With the top Perl packages precompiled, and a range of commercial support options, ActivePerl lets your team focus on productivity with Perl that “just works”.
2. Installing Perl Modules Movable Type requires various standard Perl modules for functionality. Some are required and others are optional. Check server system information by viewing the mt-check.cgi script to determine which modules are installed and which are needed. Once the Movable Type files are uploaded to the server, the mt-check.cgi script should be accessible at a url like this.
3. Perl on Mac OSX OSX comes with Perl pre-installed. In order to build and install your own modules you will need to install the 'Command Line Tools for XCode' or 'XCode' package - details on our ports page. Once you have done this you can use all of the tools mentioned above. Perl on other Unix like OSs.

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

In code -

From the shell -

From a .bash_profile or .bashrc file -

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.

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'.

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:

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

   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, as follows:

3. Run this: (local::lib assumes you have make installed on your system)

4. Now we need to setup the appropriate environment variables, so that Perl starts using our newly generated lib/ directory. If you are using bash or any other Bourne shells, you can add this to your shell startup script this way:

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

   If you passed to bootstrap a directory other than default, you also need to give that as import parameter to the call of the local::lib module like this way:

   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.

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:

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:

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:

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):

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:

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:

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.

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.

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_OPT

PERL_MM_OPT

PERL5LIB

PATH

PERL_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.

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).

Options are values that can be passed to the local::lib import besides the directory to use. They are specified as use local::lib '--option'[, path]; or perl -Mlocal::lib=--option[,path].

--deactivate

Remove the chosen path (or the default path) from the module search paths if it was added by local::lib, instead of adding it.

--deactivate-all

Remove all directories that were added to search paths by local::lib from the search paths.

--shelltype

Specify the shell type to use for output. By default, the shell will be detected based on the environment. Should be one of: bourne, csh, cmd, or powershell.

--no-create

Prevents local::lib from creating directories when activating dirs. This is likely to cause issues on Win32 systems.

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.

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.

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.

setup_env_hash_for

Arguments: $path

Return value: None

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

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.

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.

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.

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.

resolve_home_path

Arguments: $path

Return value: $home_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

Return value: $absolute_path

Translates the given path into an absolute path.

resolve_path

Arguments: $path

Return value: $absolute_path

Download Perl Module

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'.

new

Arguments: %attributes

Return value: $local_lib

Constructs a new local::lib object, representing the current state of @INC and the relevant environment variables.

roots

An arrayref representing active local::lib directories.

inc

An arrayref representing @INC.

libs

An arrayref representing the PERL5LIB environment variable.

bins

An arrayref representing the PATH environment variable.

extra

A hashref of extra environment variables (e.g. PERL_MM_OPT and PERL_MB_OPT)

no_create

If set, local::lib will not try to create directories when activating them.

clone

Arguments: %attributes

Return value: $local_lib

Constructs a new local::lib object based on the existing one, overriding the specified attributes.

activate

Arguments: $path

Return value: $new_local_lib

Constructs a new instance with the specified path active.

deactivate

Arguments: $path

Return value: $new_local_lib

Constructs a new instance with the specified path deactivated.

deactivate_all

Arguments: None

Return value: $new_local_lib

Constructs a new instance with all local::lib directories deactivated.

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.

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.

setup_env_hash

Arguments: None

Return value: None

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

setup_local_lib

Constructs the %ENV hash using 'setup_env_hash', and set up @INC.

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.

• 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::lib to a directory with spaces after you installed all modules inside your local::lib bootstrap. But be aware that you can't update or install CPAN modules after the move.

• 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.

• Kills any existing PERL_MM_OPT or PERL_MB_OPT.

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

• On VMS and MacOS Classic (pre-OS X), local::lib loads File::Spec. This means any File::Spec version installed in the local::lib will be ignored by scripts using local::lib. A workaround for this is using use lib '$local_lib/lib/perl5'; instead of using local::lib directly.

• Conflicts with ExtUtils::MakeMaker's PREFIX option. local::lib uses the INSTALL_BASE option, as it has more predictable and sane behavior. If something attempts to use the PREFIX option when running a Makefile.PL, ExtUtils::MakeMaker will refuse to run, as the two options conflict. This can be worked around by temporarily unsetting the PERL_MM_OPT environment variable.

• Conflicts with Module::Build's --prefix option. Similar to the previous limitation, but any --prefix option specified will be ignored. This can be worked around by temporarily unsetting the PERL_MB_OPT environment 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.

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.

Perl Module File

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.

IRC:

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

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

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

Doc patches for a custom local::lib directory, more cleanups in the english documentation and a german documentation 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.

Mark Stosberg <mark@summersault.com> provided the code for the now deleted '--self-contained' option.

Documentation patches to make win32 usage clearer by David Mertens <dcmertens.perl@gmail.com> (run4flat).

Brazilian portuguese translation and minor doc patches contributed by Breno G. de Oliveira <garu@cpan.org>.

Improvements to stacking multiple local::lib dirs and removing them from the environment later on contributed by Andrew Rodland <arodland@cpan.org>.

Patch for Carp version mismatch contributed by Hakim Cassimally <osfameron@cpan.org>.

Rewrite of internals and numerous bug fixes and added features contributed by Graham Knop <haarg@haarg.org>.

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

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

To install local::lib, copy and paste the appropriate command in to your terminal.

For more information on module installation, please visit the detailed CPAN module installation guide.

ActivePerl: Support your mission-critical applications with commercial-grade Perl from ActiveState – The world’s most trusted Perl distribution.

Start developing with Perl for free on Windows, Mac and Linux

The #1 Perl solution used by enterprises

Save time and stop worrying about support, security and license compliance. With the top Perl packages precompiled, and a range of commercial support options, ActivePerl lets your team focus on productivity with Perl that “just works”.

HUNDREDS OF INCLUDED PERL MODULES

• Essential tools for Perl development including CGI scripting, debugging, testing and other utilities
• Major ActivePerl components such as OLE Browser, PerlScript, Perl for ISAPI, PerlEx and Perlez
• Windows scripting with specific documentation for ActivePerl on Windows

GET YOUR APPS TO MARKET FASTER

ActivePerl includes the top Perl packages, pre-verified to ensure against outdated or vulnerable versions, incompatibility and improper licensing, so you can:

• Increase developer productivity
• Enable and secure mission-critical applications
• Satisfy corporate requirements for support, security and open source license compliance

INTEGRATED WITH THE ACTIVESTATE PLATFORM

ActivePerl, featuring hundreds of popular packages, is available free for download from the ActiveState Platform. But you can also use the Platform to automatically build your own version of Perl from source, that can include:

• Any supported version of Perl
• Thousands of packages not featured in our ActivePerl distribution
• Just the packages your project requires, such as those we’ve prebuilt for WebDev projects

Reduce Security Risks
Ensure security with the latest secure versions of Perl packages (i.e. the latest OpenSSL patch) and timely updates for critical issues.

Indemnification and License Compliance
Comply with your organization’s open source policies against GPL and GNU licensing, and reduce risk with legal indemnification.

Commercial Support & Maintenance
Keep your IP out of public forums and get faster, more reliable help with guaranteed response times and Service-Level Agreements

Enforce Code Consistency
Maintain consistency from desktop to production – Windows, macOS, Linux and big iron (AIX, Solaris).

Avoid Lock-In with Open Source
100% compatible with open source Perl so you can recruit skilled staff, ramp up faster and avoid vendor lock-in.

Accelerate Time to Market
Spend less time setting things up and more time getting things done, with the top Perl packages precompiled and ready to go.

Lack of support for open source software can create business risks. ActiveState’s language distributions offer guaranteed support SLAs and regular maintenance updates.

As much as 95% of code bases incorporate undisclosed open source code. Protect your IP with legal indemnification.

As much as 95% of IT organizations leverage open source software (OSS). However, incorporating OSS into your project often comes with licensing terms on how you can distribute your product.

How to Build Perl without a Compiler

Top 10 Python Tools for IT Administrators

The Future of Perl at ActiveState (Part 2 of 2)