Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Please, for the love of god, don't get rid of auto_install. It's the reason Best Practical uses Module::Install instead of M::B or EU::MM.

    We use it for everything we do and it's the difference between night and day for our users. (and yes, you should read that as "the difference between usability and moving off to go use PHP instead").

    I have no problem whatsoever with "gutting and redoing the mechanism that auto_install uses to be less broken", but just getting rid of it is going to lead to a world of pain
    • To clarify, it is very frequently the case that users are installing things like Jifty, Jifty applications, RT plugins and the like from the command line, not from within a CPAN process.

      Disabling auto_install if the user is already inside CPAN or CPANPLUS makes some sense, but hobbling users installing applications or modules directly is a really bad plan.
      • Are you aware of the presence of cpan . (that is, cpan dot, called from the command line)?
        • by jesse (2531) on 2008.03.19 12:16 (#61708) Journal

          No, I hadn't been aware of it. As of: cpan script version 1.9, CPAN.pm version 1.9205 it's not documented in in the manpage, either :/

          I'm not yet sure if this will solve my specific problem, though it may. But I'm known to have a big problem with backwards incompatible API breakage in CPAN modules which have been widely used or publicly available for a long time.