Bootstrapping local::lib

I'm a big fan of local::lib which is a really useful tool for isolating Perl project dependencies.  Basically it allows me to install the CPAN distributions I need when I need them without having to go through the painful regression testing associated with perl projects using global libs.  This makes developing for Perl in shared environments much more pleasant.  Using local::lib and managing my project via its Makefile.PL have become my default perl development methodology.

Using local::lib I isolate the dependencies for each project into a separate directory under my $HOME.  This allows me to quickly switch between multiple projects, each with its own dependency needs.  I use this tool so much that without it I find my work flow is seriously hampered.

Its also great for deployment as well (see Module::Install::Bundle::LocalLib for some help with this need)

However since I work on so many separate open source projects, I end up needing to create and manage a bunch of local::lib created dependency directories.  In order to help me with this I cobbled together a script based on code from http://github.com/bobtfish/catalyst-app-example-locallibapp and from the example directory of local::lib itself (see http://cpansearch.perl.org/src/APEIRON/local-lib-1.004009/eg/scripted_install.pl for the original script I looked at).

I wrote this script to help me deal with servers with seriously messed up installations of CPAN; its my attempt to create an isolated local::lib as quickly and easily as possible.  You can check it out at: http://github.com/jjn1056/bootstrap-locallib.pl where your comments, complaints and preferably patches are welcome.

Usage is straightforward.  You can wget like:

     wget http://github.com/downloads/jjn1056/bootstrap-locallib.pl/bootstrap_locallib.pl

I recommend putting somewhere in $PATH and setting it to have execution rights.  You can view documentation with the normal "--help" option but the default option is to create a bootstrapped local-lib5 directory under $HOME

    bootstrap_locallib.pl

This script creates a small helper file in your local::lib bin directory which you can use to 'activate' the local::lib for either a subshell or for one command.  For example, if you ran the above command you should now be able to:

    $HOME/local-lib5/bin/localenv perl -V

and you'll see that the @INC has been altered to include the created local::lib. It will also append its bin directory to your $PATH.

My typical usage is to create one local::lib per project, such as:

  bootstrap_locallib.pl -a html-formhandler-lib5

and then when I am going to work on that project I spawn off a bash subshell:

  $HOME/html-formhandler-lib5/bin/localenv bash

Now my sub shell has its $PATH and perl @INC altered to match the given local::lib so I can install new dependencies, etc.  When I am finished or need to work on another project I simply 'exit' and spawn off a different subshell for that project.  In this way I can manage my workflow and dependencies between all the projects I have.

Anyway, that's what I do.  Comments/corrections/improvements (and patches) welcomed!

Comments

[nperez]

[this is good] I have to say, that when I saw your repo go up on github was I was
intrigued. I've really needed something like this. The only missing
piece would be to actively version the local::lib along with the
project using git. In the grand scheme of things, it isn't that hard to
do separately. Anyhow, this really looks like a winning time saver

[miyagawa]

[this is good] Check out cpanminus development. local::lib bootstrapping is in the roadmap.

[zby]

What we now do at work to isolate our projects is using http://www.virtualbox.org/ . This is against my own inclinations - but it looks very interesting if slightly overwhelming by the lack of any knowledge base how to organize things in a setup like that.

[John Napiorkowski]

Virtual Machines are also very helpful, but might be a bit heavy handed as a tool to isolate project dependencies. For me the time lost would be prohibitive, since I need to switch often between any of a number of projects. Typically I use a VM for modeling how a possible deployment strategy might work out.Yeah, I think the Perl community is starting to grow a knowledge base of good strategies for the most common workflows. This is a good thing and hopefully in the future we can reduce the problem of how nearly every company I started at had rolled its own toolchain, and eventually become servants to it. :)I am also watching cpanminus and that seems like a very strong candidate to replace my current set of tools. Hopefully we can all come together around a process and all bang on it until its working perfectly.