http://www.perlmonks.org?node_id=694303


in reply to Yes, even you can use CPAN

My primary work product is a fairly large open source software system with users around the world. Perl is currently only used for configuring and building the other software, which is mostly written in C and C++. I am rewriting some of its Lex/Yacc/C-based programs in Perl for increased flexibility, but we don't want to have to support all our external users (who don't pay our salaries) in installing modules from CPAN and handling any version dependencies that my code has.

We can (and do) say "this software requires Gnu Make 3.81 and Perl 5.6 or later" since they are not a hurdle for most users (other than those poor guys forced to work on Windows), but to add "and the CPAN module Acme::Blah 2.2" would leave new users puzzled, increase the traffic on our mailing list, and might scare some of our users away completely.

Luckily our needs are light and most things we need are available in the core distribution so it's not that much of a loss. This is therefor one scenario where CPAN isn't necessarily useful (sorry to burst the bubble).

Replies are listed 'Best First'.
Re: Not everywhere...
by Tanktalus (Canon) on Jun 27, 2008 at 05:54 UTC

    You don't need to leave users puzzled. You can simply put the CPAN modules in with your build environment, and have make files install them. That's what I do at $work (see IT department reluctance in my original node). Our make files run a script that goes and untars the modules and runs the install process. If they're pure-perl modules, you may even be able to get away with pre-installing them (i.e., just placing their files in your tree). Of course, since you're then distributing the result, you'll want to consult with the lawyers about proper attribution and licensing, but that should cost a fraction of what developing some of the modules from scratch would be anyway.

    The only thing I can see where you can't just install or upgrade willy-nilly might be perl itself, or other external dependencies (such as Oracle if you want to use DBD::Oracle, or expat for XML::Parser). Most modules, however, should not have such a limitation. With a little thought, most other issues should be easily worked around, and even external dependencies can sometimes be worked around, too.

Re: Not everywhere...
by Anonymous Monk on Jun 27, 2008 at 06:01 UTC
    How does this prevent you from bundling these modules with your software? Or having your installer say something to the effect of:

    Oops, you don't seem to have the Acme::Blah Perl library installed. This is required for proper operation. Should I download it for you?
Re: Not everywhere...
by Anonymous Monk on Jun 27, 2008 at 05:13 UTC
    (sorry to burst the bubble)
    Your choice of words can work for or against you :)
    the act of puncturing with a small point; "he gave the balloon a small prick"