Thomas Klausner wrote:
Hi!
During YAPC::Europe in Birmingham I did a (rather short and un-hackish)
hackathon. Slides are available here:
http://domm.plix.at/talks/2006_birmingham_cpants/
During YAPC, 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)
Glad to see this included, it caught about 20 modules of mine that had
executable Makefile.PLs... although working out how the hell I managed
to do that might take a little while, I've added another step to my
release automation to stop it.
- 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
I thought we were generally negative on this one, because it would
encourage people to spuriously add trivial example directories to their
distributions...
As a secondary point, if we keep it you might also want to include
/sample(s)/ and /demo(s)/.
This resulted in quite some movement in the CPANTS game...
I've also changed the display of the authors page
http://cpants.perl.org/author/DOMM
optional metrics (is_prereq and has_example) are now visually seperated
from the core metrics.
I like the new style, not being red is a good thing.
The site 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
It might be an interesting idea to also add a "dependencies_exist"
metric, that makes sure that all the dependencies that are declared
actually exist in the CPAN. Dunno, could be of dubiously little value,
but I just managed to somehow upload something with bad deps that I had
installed on my local machine, but that weren't all on CPAN yet...
- no_open_bugs
If we are going to do this, we have to make sure that we DON'T include
wishlist bugs in this metric, or it blows the validity all to hell.
- Signature checking ?
I looked into this a bit more recently, with all the Module::Signature
changes. I think this is a bad idea.
Signature checking HAS to be done by the CPAN client, and NOT ever by
the module itself, because it limits the ability of the client to modify
or tweak files (for example, we might potentially want to have
Makefile.PL alter the META.yml to localise the deps for the current
platform).
By the time make test runs, it's WAY too late to be checking signatures.
has_signature is fine, but another test along the lines of the Test::Pod
and Test::Pod::Coverage ones would be a bad idea.
- has_rating ?
Bad idea I think as well, because it will encourage spurious ratings.
This is the same reason that ratings aren't factored into the
search.cpan result order. CPAN Ratings currently has most of it's value
because it doesn't matter much, and so it encourages high quality reviews.
Anything that would make the quality of the reviews worse (or malicious)
isn't a negative thing.
- relation of subs to lines of code ?
Dubious. Makes a naive and blanket judgement call.
Adam K
