in reply to modules out of the box

Please don't include anything in your distribution that uses a CPAN-registered module name. I've been bitten more than once on that, the most memorable being the "Minivend" shopping cart package.

The "Minivend" author started with the attitude you had: he had wanted to make a "turnkey" solution for end users, and needed some modules that perhaps were not commonly installed, so he had included frozen versions of them into his distribution, under the original names.

Well, time passed, and he didn't incorporate the latest version of those modules into his distribution, but it came time for me to install Minivend to test it to see if I wanted to do a column about it. Imagine my horror when Minivend uninstalled my more modern versions of those handful of central modules, and replaced them with his own downrev versions!

I immediately posted a note to his support list and to P5P warning people that "minivend is evil", and got some interesting responses, but mostly the P5P group sided with me: a distribution should not have private versions of public modules under the CPAN-registered name. This leaves him (and you) with two solutions:

  1. Include (as you suggested) a version of the module, but safely tucked away under your own namespace. Like a version of Minivend::Foo::Bar for a module that everyone else knows (or once knew) as Foo::Bar.
  2. Simply list the prerequisites in the Makefile.PL, and let the installer sort it out.
The latter is highly preferred, although the former insulates you from any "upward compatibility" problems, but most modules I've seen only get better, and have sacrificed very few items in the name of backward compatibility.

The "Minivend" author learned his lesson, and now does the latter. I suggest you seriously look at doing the same. Do you really think a site can be self supporting if they can't even install a module or two from the CPAN? There is a support cost to using Open Source software, and part of it includes being able to include components. If they want Microsoft, they know where to get it. {grin}

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: RE: modules out of the box
by knight (Friar) on Sep 05, 2000 at 19:30 UTC
    Good point. I didn't explain one thing clearly, though...

    We don't actually ship our own, separate Spec.pm file (e.g.). Since Cons is a single script, we just "package File::Spec" within the script itself, and thus don't go outside to look for any module. I think this sidesteps the issue of causing trouble for anyone else's module installation, but let me know if I'm overlooking something.

    Do you really think a site can be self supporting if they can't even install a module or two from the CPAN?

    No, but that's not what we're trying to solve. We're trying to make it easy for someone to pull down the tool and experiment with it, regardless of how much their IT department has their system locked down. During the initial experimentation phase, every barrier they run into becomes a point at which they can say, "I'm not getting anywhere with this," and go do something else. We're trying to remove as many of those barriers as possible, so that any programmer can try Cons with a minimum of fuss, see how cool it is, and then figure out how to get their department to use it for real...
      Then one solution would be to include Spec.pm with your distribution, and have your Makefile.PL install it as Cons::Spec (or whatever namespace the CPAN registrars gave you) in the absence of a detected suitable File::Spec. You can load the code in your modules like this:
      BEGIN { for (qw(Cons::Spec File::Spec)) { eval "use $_"; last unless $@; } die "Cannot find Cons::Spec or File::Spec" if $@; }
      A little bit of runtime launch cost can provide a ton of flexibility for your installers. If you want, you can even edit this at compile time into a simple use File::Spec, and avoid the runtime cost.

      -- Randal L. Schwartz, Perl hacker