Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • Perl packagers should install Bundle::CPAN with any new installation -- this is the approach Vanilla Perl takes and the result is quite sane for installing any module. It's reasonable to put this onus on packagers -- it's like ensuring that bugfix packages on any older piece of software are in place.

    Don't use Autoinstall -- most of the gyrations you describe are just to fix the problems this creates. The module toolchain should leave it to CPAN/CPANPLUS/etc to resolve dependencies. Makefile.PL just n

    • Unfortunately, even if everyone did bundle Bundle::CPAN, that only solves the problems that have occurred in the past. It doesn't solve the problems that will occur in the future.

      To most of the old Perl distributions out there that predate the invention of the new generation of toolchain modules, they all worked just fine at the time. It was the future that bit them.

      And so we need to try to deal with the bugs that we don't know have happened yet in the toolchain.

      As for AutoInstall, you are superficially correct. At this point I'm all for a Kwalitee decrement for using auto_install in a Makefile.PL.

      HOWEVER, unfortunately Module::AutoInstall contains large portions of required functionality. Things like the implementation of feature() and anything that handles prompts to the user.

      So some of the dangerous functionality gets loaded ANYWAY. :(

      Add to the the problem of targetting both Module::Build and ExtUtils::MakeMaker and this encapsulation of the "playing well with others" code is really needed anyway in order to deal with the larger problems throughout the internals of Module::Install.