David Golden wrote: >> Well, EU::MM *cannot* be patched on the clients without >> configure_requires. So, the best it could do would be to warn the >> author about it at `make dist` time. > > I still think it should be patched so that anyone installing > Bundle::CPAN gets a version that handles it.
Are you suggeting that ExtUtils::MakeMaker go into Bundle::CPAN? That's a very good idea. > Again -- EU::MM doesn't break if 'perl' is in PREREQ_PM -- it just > warns that the 'perl' module can't be found. The patch I wrote for > EU::MM just handles that special case in a cleaner way. Schwern may > not take it -- he doesn't like special cases, so he's thinking about > another MakeMaker variable instead. Either way, I'd prefer to have a > formal way to specify a perl prerequisite rather than a "convention" > of dying during Makefile.PL and then having other toolchain modules > have to parse the output to figure out why. If parsing the error message is a "convention" that should be avoided, why is parsing out the prerequisite warning not? In addition the treating the "perl" prerequisite failure not as a module but something else is a special case that the whole toolchain has to learn. Finally, even putting "perl" into META.yml as part of requires is a convention, the toolchain has to know not to treat it as a module. This is not to say I don't agree with you about require being a convention, but they're all special cases, hacks and conventions. Until META.yml has a proper way to explicitly declare non-module dependencies its pretty much all convention. The nice part about the "require" failure is it always works, at least in the "stops the build" part. And everything knows how to parse the error already.
