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

Daniel Pittman daniel at rimspace.net
Sun Jun 1 21:16:08 PDT 2008

Paul Fenwick <pjf at perltraining.com.au> writes:
> 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.

The one other interesting feature of PAR, which I have yet to
investigate, is that it can use an HTTP URL as a source for the PAR

That requires PAR::Repository::Client, but seems like a reasonable
approach to ensuring that your client machines are consistent in their
use of third party modules.


If you /do/ use it, let us know, eh?

More information about the Melbourne-pm mailing list