I was attempting to breathe life back into Karen E.'s clean and tidy suggestion, by answering David G.'s backward compatibility objection.

A distro with a properly declared ancient perl version in its meta data should be scored as if it had "use warnings" declared in each of its components. "no warnings" and "use warnings" should be treated as equivalent for the purposes of the test. This expresses the idea that the author has some settled opinion about warnings (5.6+), or is prevented from making this explicit by an overriding compatibility requirement (pre-5.6).

If the parser does not have easy access to the meta data, an alternative (somewhat clumsy) mechanism would be to declare the version in the package:

package Camel::Dung;
use strict;
use 5.004_05;
#no warnings;
...

If you are troubled by the idea that authors could fiddle the score by unsubstantiated claims in the meta data, syntax could be checked using the appropriate perl rev with appropriate penalty point tariff applied.

That's an interesting idea. Whether from metadata or from code, declaring an old perl version as a dependency then scores warnings differently. Even use 5; would be enough if someone doesn't want to have an explicit opinion about how far back to support.

That doesn't help with strict, but then I'm fine with the idea that "no strict" is used to be explicit.

package Grotty::Guts;
use 5.004;
no strict;

That would work for me and avoids junking up META.

As of this writing...

• CPANTS analyzer does have access to META data, and knows if use 5.xxx exists or not in each file.
• Module::ExtractUse (which CPANTS uses internally) doesn't recognize no stuff. I suppose this is fixable, but I doubt if it's worth trouble and cost.
• use_warnings is an extra metric, and it doesn't affect the game score.

I don't think it a good idea to modify the behavior of use_warnings (or anything) by the declaration of an ancient perl version, because that makes it harder for visitors to know if the module/distribution really warns when necessary or not. Keep it simple and self-explanatory.

I'm also supposing x_cpants (or whatever) is just to ignore some metrics when calculating the final (game) score, not to tweak the result of analysis itself. All the fails, all the errors should be recorded regardless of x_cpants, so that we can investigate them later, or take some statistics.

The 'use warnings' test is meaningless when applied to a distro declaring a dependency on pre-5.6 perl in its meta data. Whether you record a "pass" or "N/A" in the database, and where in the code you do it, are matters for you decide. It is gross miscarriage of justice to penalise code merely for still being alive after 15 or 20 years.

'use warnings' and 'no warnings' are equally good indications that the author has engaged with the topic sufficiently to decide one way or the other. There is no need for CPANTS to record whether the negative form of pragma was used, or to do anything different with it. Knobbling the front-end of the analyser to turn 'no warnings' into 'use warnings' on the fly would solve the problem admirably. Deal with 'no strict' in a similar way. There is clearly some value in doing this, otherwise nobody would be discussing it here.

On Sat, Mar 22, 2014 at 07:20:21AM -0700, rwfranks wrote:

The 'use warnings' test is meaningless when applied to a distro declaring a dependency on pre-5.6 perl in its meta data. Whether you record a "pass" or "N/A" in the database, and where in the code you do it, are matters for you decide. It is gross miscarriage of justice to penalise code merely for still being alive after 15 or 20 years.

"penalise" is a bit harsh since this is just a heuristic. No one's being
sent to jail or anything. I'm not going to cry into my cereal because some
of my dists are failing other metrics (for instance prereq_matches_use,
which sometimes is impossible to pass).

Here's a suggestion for a way forward: we could introduce a third state for
all metrics: "pass", "fail", or "mu" (insufficient information to provide
an assessment). For distributions that explicitly state a perl version
prereq, and it is earlier than 5.6, give the 'use warnings' metric a
"mu". If no perl prereq is stated, they fail both that metric and the "use
warnings" metric (if the warnings pragma is not used). Likewise, a literal
"no warnings" will generate a mu. This score will not be calculated in the
overall total at all - e.g. the score will be calculated out of 130 rather
than 133.

As for use_warnings, there is a way to pass even for pre-5.6 perls (use warnings::compat). So, using it or not is just a matter of choice. (FYI, the current analyzer counts strict/warnings equivalents as well, though there was a bug in MCA and it wasn't counted correctly).

no warnings/strict (or their equivalents) are not always used to show a module is totally warnings/strict-free. I don't want to turn no Moose into mu :p

That said, introducing a third state is a todo that I couldn't finish during the QAH this year. I thought of missing META.* for META related metrics etc, and also of tentative metrics (such as prereq stuff) that can't be determined until everything is settled, but it might be applicable to use_warnings as well.

Being able to exclude files or directories from Kwalitee checking would mean that testing files aren't picked up in error: http://cpants.cpanauthors.org/dist/Dist-Zilla-Plugin-NexusRelease-0.0.1/errors

All 3 of those fails are for a file that's there to be used as a test subject; and one of the fails is that the test subject library isn't in the lib/ directory...

@brad-mac that's because you haven't excluded anything. See the following:
https://metacpan.org/pod/CPAN::Meta::Spec#no_index
https://metacpan.org/pod/Dist::Zilla::Plugin::MetaNoIndex
https://metacpan.org/source/RJBS/Dist-Zilla-5.031/dist.ini#L14

Nice - and that's documented now (assuming other people go through the same set of Google searches I did and end up here) in a way that I find a bit more obvious. There wasn't anything that jumped out at me about indexing in the Test::Kwalitee docs or on http://cpants.cpanauthors.org/kwalitee.

Thanks!

@charsbar I think it's the meta 'provides' field that's significant here, not no_index?

https://metacpan.org/source/ISHIGAKI/Module-CPANTS-Analyse-0.96/lib/Module/CPANTS/Kwalitee/FindModules.pm#L20

(for @brad-mac I use [MetaProvides::Package] to set this data in my distributions.)

@karenetheridge whichever is ok as long as it excludes stuff in corpus/ directory correctly. use_strict/use_warnings metrics are only applied to public modules.

Thanks Karen - much better than my first attempt with [MetaProvides::Class] :-)

@charsbar, I've forked M:C:A and added some documentation to the 'remedy' for 'proper_libs' - hope that's up to scratch.

@brad-mac, thanks. The source of your fork is an old one, but applied it by hand anyway: cpants/Module-CPANTS-Analyse@b6a525e

More usecases for this metadata:

• Crypt-SSLeay to ignore the "inconsistent versions" check (see Inconsistent version for Crypt::SSLeay Module-CPANTS-SiteKwalitee#4)
• Acme-Pi (also has intentionally inconsistent versions between module and distribution).