>>>>> On Sat, 21 Jul 2007 19:03:03 -0700, Michael G Schwern <[EMAIL PROTECTED]> >>>>> said:
> 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. It is now. I was *quite* surprised to learn that is was not. >> 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? Nobody is parsing the prerequisites warning, we are only parsing specified prerequisites. > 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. As far as CPAN.pm is concerned, the lesson has been done. Read the META.yml spec. It does not say it explicitly that 'perl' is a special case but the example in the SYNOPSIS contains C< perl: 5.005_03 > So this was specification enough for me to implement this special case. No, I have to correct myself, it was not enough. I did gather statistics how wide spread it was and then decided. I still have this file here -rw-r--r-- 1 k k 1568360 2005-12-23 22:06 count-yaml-requires.pl.out On this day we had already 462 distributions using 'perl' in the requires field. So this was enough of an argument for me. > 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. Dieing and leaving the toolchain with the duty of parsing error messages is quite the crappiest solution I can imagine. If we have the chance to deal with properly specified metadata we should take it. I agree that stealing 'perl' from the modules' namespaces is a hack but still better than dealing with error messages from dying programs. IMHO. > Until META.yml has a > proper way to explicitly declare non-module dependencies its pretty much all > convention. Reread it! > 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. I think it's fine if parts of the toolchain die when they have properly declared their metadata. Declaring the perl version we depend on is essential and there is a spec that tells you how to do it. -- andreas
