non-standard package management

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

Replies are listed 'Best First'.
Re: non-standard package management by perrin (Chancellor) on Oct 13, 2005 at 18:33 UTC
Bundling modules into your own distribution has worked great for us. What I use now is based on the build system in the Krang CMS. The CPAN sources are bundled with the software, and there is a build script that builds and installs them all to a local lib directory, making them available to all programs withing the distribution and avoiding any issues of updating system libs. With this approach, you can even have multiple copies with dependencies on different versions of the same modules installed on the same machine.	[reply]
Re^2: non-standard package management by bluto (Curate) on Oct 13, 2005 at 19:21 UTC
With this approach, you can even have multiple copies with dependencies on different versions of the same modules installed on the same machine. This is a great idea in general. There are other benefits as well, esp if you don't have access to the target machine (e.g. you really need the most up to date module and a sysadmin you are dealing with may balk at installing it for you because it could break someone else's code; sysadmins with their own fiefdoms may not want to bother installing any extra stuff in addition to your modules; you want to give a normal user the ability to install/use your module; etc).	[reply]
Re^3: non-standard package management by johnnywang (Priest) on Oct 13, 2005 at 19:41 UTC
Lucky bluto, yours is the 500,000th post on PM!	[reply]
Re^4: non-standard package management by bluto (Curate) on Oct 14, 2005 at 15:19 UTC
Re: non-standard package management by g0n (Priest) on Oct 13, 2005 at 18:53 UTC
It's an interesting question. As far as discussion rather than suggestions goes, on the one hand, CPAN modules are an important part of what makes Perl as flexible and powerful as it is. On the other hand, the range of modules installed does varies according to the distribution. As I've commented before, I've seen distributions of perl that omitted `strict`! There's a judgement call to be made for using modules in any perl code implementation, based on a number of criteria, some of which are: How much pain does it cause you not to use a non core CPAN module? There are modules that implement functionality you can replicate without too much work, but no one in their right mind will attempt to replicate Net::LDAP or DBI to avoid installing the modules. How difficult is it really to install modules on the machines that you're running the code on? Often the reasons are political - absence of a compiler, brutal change control policies written by non-techs etc Is the code going to run on varying versions/distributions of perl? Tk is included in Activestate, but not in the core perl source code, and other modules are similarly included in some distributions and not others. You say that Perl is included with your OS, but not what OS it is - if you're working with multiple OS's, the version/distribution of perl installed could vary. For my part, having suffered in the past with c compiler dependencies, I sometimes accept a speed hit in favour of using pure perl modules or writing the functionality myself, or if a module contains functionality I can easily replicate I may not bother using the module at all. That said, there are some things (Net::LDAP & Data::Dump::Streamer for example) that require c compilers and I simply cannot do without or work around. I do think that by avoiding using non core modules you are probably making life more difficult than it needs to be - a fairly up to date version of perl will include CPAN.pm, which provided the machine is net connected makes dependency resolution a) easier, and b) automatable, and as 5mi11er said, you can always state what's needed for your code to work. (and if anyone is thinking I've changed my tune, I have. I'd like to think I've learned something). -------------------------------------------------------------- $perlquestion=~s/Can I/How do I/g;	[reply] [d/l]
Re: non-standard package management by radiantmatrix (Parson) on Oct 13, 2005 at 20:16 UTC
If you can depend on the `make` application being there (it usually is on NIX systems), then you should look into ExtUtils::MakeMaker. This is the same thing CPAN modules use to get installed. Basically, you construct a `Makefile.PL` that enumerates where you should be installed and what dependencies you have. You could write a small, general-purpose installer that uses the CPAN module to make sure those dependencies are downloaded and installed automatically. <-radiant.matrix-> A collection of thoughts and links from the minds of geeks The Code that can be seen is not the true Code* "In any sufficiently large group of people, most are idiots" - Kaa's Law	[reply] [d/l] [select]
Re: non-standard package management by 5mi11er (Deacon) on Oct 13, 2005 at 18:34 UTC
Hey BigTiny, Use <p> to separate your text into paragraphs, and see Writeup Formatting Tips for further information about how to 'markup' your posts. The easiest way to get around the problem is to publish the dependancies the tools use. It is then up to the person attempting to use the package to ensure the appropriate modules are installed. Otherwise, there are several "packaging" options, PAR is one I've seen thrown around the monestary a lot lately... -Scott	[reply]