[Melbourne-pm] How to build a local module repository

[Paul Fenwick]

G'day Ian,

Ian Macdonald wrote:

> Does anybody have any better ideas, or can see problems with where we're 
> going?

I agree with Toby's comments about using the native OS packaging system, but 
I'm not sure if any such thing exists for Windows.

I believe that using CPAN::Site or a similar technology (eg, CPAN::Mini) to 
essentially make your own CPAN is a fine idea.  It means you get the modules 
you want, in the locations your Perl expects them to be.  However I've not 
used either CPAN::Site or CPAN::Mini, so I can't comment on its 
effectiveness.  It certainly sounds like the traditional thing to do.

Depending upon your circumstances, you may also wish to use PAR.  You'll 
take both a space and a time hit on start-up, but it makes it very easy to 
bundle all the modules you need into a single archive, and then use that. 
For example, you can bundle all the modules required by a program into a 
single file with:

	pp -p -o mymodules.par myscript.pl

You can then include in your program:

	use PAR 'mymodules.par';
	use Foo::Bar;
	use Bar::Baz;

and your code will automatically extract and load them from mymodules.par if 
they exist.

You can even run the .par file directly (since it will also contains your 
script) with:

	parl mymodules.par

Perl Training Australia has recently written a Perl tip on PAR at:

	http://perltraining.com.au/tips/2008-05-23.html

PAR has pretty minimum dependencies.  Distributing it to your target 
machines should be easier than distributing all the modules.  In fact, you 
can even use PAR to build stand-alone .exes that don't require perl at all, 
or .pl files which contain their own module archive.  Of course, you'll take 
  a speed and space hit to do so.

However, using PAR isn't all roses.  You should be aware that:

	* You'll take a time AND space hit by using PAR, since
	  modules will need to be extracted from the .par file.
	  This isn't too bad, since PAR will cache the extracted
	  modules locally, so you only get a big hit the first time.

	* There's currently a bug in parl, because it *always* uses
	  the same cache directory.  This means that if you have two
	  different programs built into .par files, and they contain
	  different versions of the same module or file, then only
	  one of those modules will ever get used.

	* It doesn't always work with all modules.  In particular, if
	  there are .dll or .so files that need to be bundled, you may
	  have to provide hints.  In our perl-tip we've got a link
	  to SweeperBot's builder, which demonstrates how to link in
	  the various Image::Magick .dll files.

	* Unless you're using pure-perl modules, you'll need a full
	  install of all the modules you want to use on a system
	  with identical architecture where you're using 'pp' to build
	  your .par files.

	* Systems built with PAR won't necessarily pick up upgraded
	  modules that are on your systems; so if you're already going
	  to the work of maintaining good installs of all your modules,
	  PAR may make your distribution headaches worse.

> PS on a related note; we've also thought about installing CPAN modules 
> on new boxes by simply copying the perl/site directory from a working 
> box. Assuming that the OS matches down to the patch level, is this a 
> safe approach?

Well, you'll hit the same problems as we do with PAR when there are .dll/.so 
or other dependencies that don't necessarily live in perl/site.  It also 
sounds rather difficult when it comes to backing out the changes; with a 
.par file you just delete the file.

I've not tried copying the directories myself, so YMMV.

Cheerio,

	Paul

-- 
Paul Fenwick <pjf at perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681