Bundling perl modules with a larger system

mattsheppard has asked for the wisdom of the Perl Monks concerning the following question:

I'm currently tasked with managing the packaging and installation for a reasonably large system which uses Perl extensively. To date we've manually built some modules from cpan to bundle along with the product, but for some larger hierarchies (where modules depend on others and so on), it becomes quite complex and time consuming to do this by hand.

Unfortunately requiring the end user to install modules outside the Perl 5.8 core set on the local machine isn't an option for us, and I wouldn't have thought trying to script MCPAN during our installation would be a good idea either (though I'd be open to convincing).

I guess my question is, is there a better way? It would be really nice to use MCPAN, to install packages to a clean directory, then pull the results out and into our bundle, but I worry about missing some dependency because it happened to be pre-installed in the host version of perl.

A second complication is that I would really love to be able to ship with modules which use XS, but that means providing separate pre-compiled versions for each of the four architectures we support. I'm not sure if there's some simple trick for handling that, or if it just means doing everything four times over.

Anyway, here's hoping this is one of those 'Oh, clearly you haven't heard of XYZ which make it all very easy' type questions.

Comment on Bundling perl modules with a larger system

Replies are listed 'Best First'.
Re: Bundling perl modules with a larger system by citromatik (Curate) on Dec 20, 2007 at 10:03 UTC
Maybe this solution doesn't fully resolve your problem, but I think that create a personal module bundle would help you The idea is to create a new bundle of modules, store it and install whenever and whatever you want The autobundle command from CPAN takes a catalog of what you have installed on your system: `$ cpan cpan> autobundle [...] Wrote bundle file /usr/src/.cpan/Bundle/Snapshot_2007_12_20_00.pm` [download] If you prefer to make your own Bundle and include a list of modules you can do it like: `package Bundle::Personal::Modules 1; __END__ =head1 NAME Bundle::Personal::Modules =head1 SYNOPSIS perl -MCPAN -e 'install Bundle::Personal::Modules' =head1 CONTENTS #Here your modules... Data::Dumper Test::Pod # etc...` [download] Then, you can copy that bundle to another machine (under the Bundle/ directory beneath the CPAN module's working directory and: `$cpan cpan> install Bundle::Snapshot_2007_12_20_00.pm` [download] You can set `cpan` to follow all prerequisites without asking when configuring it for the first time. Hope this helps citromatik	[reply] [d/l] [select]
Re: Bundling perl modules with a larger system by Fletch (Bishop) on Dec 20, 2007 at 02:19 UTC
~~So, erm, have you heard of par? :)~~ Update: Bah, mislink. See two nodes down please . . . The cake is a lie. The cake is a lie. The cake is a lie.	[reply]
Re: par by mattsheppard (Acolyte) on Dec 20, 2007 at 02:50 UTC
No, can't say I had - Looks like a way of bundling a bunch of files into a single perl script, which unpacks itself (like a self extracting archive), yes? Actually unpacking the files onto the file system isn't a big issue for me, I guess I'm more concerned with finding an easy way to work out (and ideally build) the files which need packing. Maybe an example... Say I want to ship Archive::Zip along with my app. From the readme I find that it requires Compress::Zlib, which then appears to require the IO::Compress::Gzip, IO::Uncompress::Gunzip, Compress::Raw::Zlib and so on. What I'd like, is a way to build all the dependencies in one hit, so I can bundle up the result, but I'm worried that just using MCPAN with something like PREFIX=/tmp/matts_new_build_area would skip Compress::Raw::Zlib if that happened to be installed locally on the box. Hopefully that makes the issue I'm running into a little clearer. Thanks, Matt Sheppard	[reply]
Re^2: par by Fletch (Bishop) on Dec 20, 2007 at 02:53 UTC
GRAH, sorry that was a bad link. I plead head cold . . . I mean PAR (and http://par.perl.org/) which is a different beast altogether. That lets you package a script and requisite modules into a single executable archive. The cake is a lie. The cake is a lie. The cake is a lie.	[reply]
Re^3: par by mattsheppard (Acolyte) on Dec 20, 2007 at 03:38 UTC
Re^2: par by holli (Abbot) on Dec 20, 2007 at 12:26 UTC
Have a look at cpandeps holli, /regexed monk/	[reply]
Re: Bundling perl modules with a larger system by snowhare (Friar) on Dec 20, 2007 at 23:34 UTC
You didn't say what platforms you are supporting, but if they are ones that uses RPM, you might want to look at cpan2rpm. I just completed packaging over 300 modules for use here using it (it took me about 3 days of work). Combined with the yum package manager (and using the createrepo package to generate a Yum repo out of them) it makes installing those 300 modules on a new machine a matter of minutes. I _literally_ just say 'yum install perl-*' at the shell and 10 minutes later am done. A slightly different approach if you are using a Redhat derived system is use the pre-built RPMs on RPMForge if you have network access and are willing to trust modules built by a third-party.	[reply]
Re: Bundling perl modules with a larger system by ysth (Canon) on Dec 25, 2007 at 23:52 UTC
I'd strongly encourage you to not install to your customers machines directly from CPAN. You want the opportunity to be the first to know when one of those CPAN modules (or how you use it) breaks, not leave it to your customers. And installing specific versions of distributions from CPAN is out because you never know when authors will clean up their directories. Which leaves you doing your own distribution and installation of known good versions. But then you have the headache of possibly dealing with the customer using perl for other things and with their own module version requirements. Put all that together, and the ideal solution starts to look very much like PAR. -- CollegeGear.com - more than just college gear (though, yes, we have college-branded teddy bears)	[reply]