All the Perl that's Practical to Extract and Report

Post-YAPC::Europe CPANTS news

domm on 2006-09-06T09:26:30

During YAPC::Europe in Birmingham I did a (rather short and un-hackish) hackathon. Slides are available here.

I added a few new metrics:

  • manifest_matches_dist
    Check if the stuff listed in MANIFEST matches what's in the dist
  • buildtool_not_executable
    Check if the buildtool (Makefile.PL, Build.PL) are not executable (and thus need to be called with 'perl Build.PL' thereby specifying which exact version of Perl you want)
  • has_example
    An optional metric that checks if the author included a dir called 'eg|ex|example(s?)' which in turn includes at least on *.pl

This resulted in quite some movement in the CPANTS game...

I've also changed the display of the author pages, optional metrics (is_prereq and has_example) are now visually seperated from the core metrics.

The site http://cpants.perl.org is still not very stable due to a Catalyst/DBIx::Class-Bug (or more likely a bug in my usage of them).

Oh, and if you want to join the fun and help a bit, here's a (probably incomplete) list of tasks:

  • Metrics:
    • has_license
    • no_boilerplate
    • has_valid_filenames
    • declares_dependencies
    • no_open_bugs
    • Signature checking ?
    • has_rating ?
    • relation of subs to lines of code ?
  • Scripts
    • Generate a SQLite DB dump from the postgres DB
  • Catalyst Frontend
    • sqash bug
    • Split up dist/view into several sub-pages
    • API / Webservice

Just my 0.02

jk2addict on 2006-09-06T11:59:24

But you should also add 'demo' and 'demos' to the list of examples directories.

Re:Just my 0.02

jk2addict on 2006-09-06T12:02:46

For that matter, I'm not so sure about the 'at least one *.pl requirement'. It may very well be a non-perl demo, aka site code like .xsp ot .tt pages that requires no pl file; but they're examples non the less.

Yes, I'm biased, and that .pl file is going away now that I'm using DBIC. :-)

Re:Just my 0.02

bart on 2006-09-07T13:23:42

And "samples".

Thoughts

ChrisDolan on 2006-09-06T15:00:50

Cool!

Some ideas:

1) Document/discuss possible future metrics on the Perl-QA wiki

2) For each metric, document the aspect of Quality that is being judged and how the Kwalitee metric is a good proxy for it, and/or possible other proxies. For example, consider the software goal of "Good documentation". Currently that metric follows the following chain of proxy metrics:

    Good documentation => 100% POD coverage => has t/.*pod.*coverage.* file

A better proxy might be for CPANTS to run Pod::Coverage itself, thus:

    Good documentation => 100% POD coverage => passes Test::Pod::Coverage

Another possibility (not a good one, just an example):

    Good documentation => cpanratings.org ratings of docs

And we don't have to choose just one. As I argued on the Perl-QA list, the more metrics the better. More metrics makes CPANTS harder to gain, and lets us apply weights to the metrics we like best.

3) Other possible metrics:
  * is_ascii_or_unicode - avoid Latin-1, Shift-JIS, etc in code
  * consistent_newlines - proposed by Adam Kennedy on Perl-QA in April
  * has_synopsis - usage examples in POD (David Golden, in March on Perl-QA)
  * does_synopsis_compile - this is a sketchy one
  * has_meta_yml_license - check for a META.yml field named "license"

4) Some of the Perl::Critic policies might be universal enough to be CPANTS metrics

Re:Thoughts

jk2addict on 2006-09-06T19:01:59

consistent_newlines - proposed by Adam Kennedy on Perl-QA in April

Was that consistent newlines per file, or per dist? Some dists have legit reason to have some files native line endings and some files w/ non-0native line endings. I've done it in Handel. Some things just don't work in windows unless the file has *nix line endings, like __DATA__ vs. __END__ in some situations.

Re:Thoughts

ChrisDolan on 2006-09-07T04:04:27

Per file. That's important to prevent Module::Signature breakage.