[Melbourne-pm] How to build a local module repository
pjf at perltraining.com.au
Sun Jun 1 21:01:57 PDT 2008
Ian Macdonald wrote:
> Does anybody have any better ideas, or can see problems with where we're
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';
and your code will automatically extract and load them from mymodules.par if
You can even run the .par file directly (since it will also contains your
Perl Training Australia has recently written a Perl tip on PAR at:
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.
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
More information about the Melbourne-pm