On Thu, Feb 19, 2009 at 9:35 AM, Marc Lucksch <p...@marc-s.de> wrote: > And what about the optional Test::NoWarnings? > If it isn't in build_requires, I get bad kwalitee, if its there, the module > will be installed without being really needed. If I hide it with trickery > from being detected, I will fail the *uses_test_nowarnings*.
Kwalitee should serve the author. The author should not serve Kwalitee. (c.f pod testing and the reason xt was established as a standard) > The only modules required for the build process (without make test) are > ExtUtils::MakeMaker, Module::Install and Module::Build. Not always. You can have Foo.PL files that are run during make/Build and that require any module you want. >> Usually, discussion seems to happen on the module-build mailing list, >> but last year the QA Hackathon seemed to be the place to debate >> extensions like the one you mentioned. There was some consideration >> last year of breaking out build/test/install requires further but >> there was no consensus for it. One of the issues is that it >> introduces yet another round of CPAN/CPANPLUS upgrades, so in your >> example, you'd need to have a "configure_requires" that lists a newer >> CPAN/CPANPLUS. > > Do CPAN/CPANPLUS die on entries of META.yml they don't know about? They > could should ignore it since most are not needed anyway, except > test_requires. The discussion focused on breaking out "build" vs "test" phase requirements, not xt stuff. Thus, CPAN/CPANPLUS would need to know about test requirements for tests to pass. > I don't really see a problem in people updating their CPAN or CPANPLUS. That's right, you don't. But others do. You seem to think that volunteers should patch CPAN, CPANPLUS, Module::Build, ExtUtils::MakeMaker and Module::Install, plus all the tools that utilize META.yml for analysis today and that users should upgrade those tools universally so that you can get a point of Kwalitee. That's absurd. The Kwalitee analyzer shouldn't look in xt. Period. Look -- I'm not trying to bash the idea of splitting build/test requires in META.yml. I'm actually in favor of it in the abstract. But the challenges in doing so across the Perl toolchain and ecosystem are not trivial. The best case for it I heard came from the Debian packagers, I think, and as I said, in Oslo, a group a very smart, opinionated people talked it through and couldn't come to a consensus on a path forward and didn't seem to think it was a priority relative to other things. (Like getting configure_requires support into core so there's a glimmer of hope that we'll have a path towards being forward compatible in the future.) I'd rather see energy directed to cleaning up some of the Kwalitee metrics that are sub-optimal. -- David
