in reply to RE: modules out of the box
in thread modules out of the box

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...

Replies are listed 'Best First'.
RE: RE: RE: modules out of the box
by merlyn (Sage) on Sep 05, 2000 at 20:17 UTC
    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 $@;
}

    [download]
    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

[reply]
[d/l]

In Section Meditations