[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
archive.
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.
Regards,
Daniel
If you /do/ use it, let us know, eh?
More information about the Melbourne-pm
mailing list