Front page | perl.module-authors |
Postings from June 2008
Re: Fwd: New CPANTS metrics
From: Thomas Klausner
June 10, 2008 11:54
Re: Fwd: New CPANTS metrics
Message ID: 20080610185121.GA29188@d610.o.factline.com
Uh, wow, why do CPANTS discussions always start when I'm low on tuits...
A lot of your issues have already been addressed, and as my time is
short ATM, I'll only awnser some of the remaining
> extracts_nicely: How much of a problem is this, really?
A lot of people hate tarballs/zip-files that spew their content into the
current dir. Especially if the offending dists contains lots of files.
Or a file with the same name as one you had in the dir...
> has_buildtool: How many CPAN modules does this even apply to?
> has_working_buildtool: ditto
This metric was introduced to list dist that come with outdated versions
of Module::Install. It might of course be extended to problems in other
buildtools (say, if MakeMaker becomes deprectated)
> metayml_conforms_to_known_spec: valid metric; how useful is this, though?
> metayml_is_parsable: Isn't this redundant to "conforms to known spec"?
well, something might be parsable, but not conformant.
> metayml_conforms_spec_current: Yeah, whatever.
> extractable: How many CPAN modules have EVER been released with a
> weird packaging format? Is this addressing a real problem in the
There are some very ancient dists that don't extract. In the first
verions of CPANTS this was actually reported, but currently dists that
fail this are completly ignored. Which is a bug...
> * Finally, we come to the large body of misguided and unuseful tests:
> has_test_pod: Useless. Why should every end-user have to test the
> correctness of the module's POD? The original developer should test
> it, and the kwalitee metric should test that the module's POD is
> correct (no_pod_errors). Including it as part of the module's test
> suite is useless.
While the current implementation definitly sucks (and should be changed
to work with The Oslo Consensus), I think this metric is valid. For
example, it makes sure that somebody who takes over maintainership
(without access to the authors work environemt (maybe the author died or
is just missing)) has everything she needs.
> no_cpants_errors: Module author should not be dinged for bugs in
> CPANTS testing.
no_cpants_errors is the best way to get some feedback from authors.
CPANTS got lots of improvements because authors complained (rightly)
that CPANTS was failing in interesting ways and caused their
no_cpants_errors metric to be flagged red.
As you might imagine, some dists contain some very sick/interesting
things. And I might have a twisted mind, but not twisted enough to come
up with every absurdity the combined crazyness of CPAN authors gives
> proper_libs: Misguided. Why should end-users care about the
> structure of the module build tree? They shouldn't.
CPANTS is not only targetted at end users. In fact, its focus shifted to
helping developers write nice dists.
> use_strict: Misguided. "use strict" is a valuable tool for
> developers, but it is not necessary (or even desirable) in all
Huh? Do you us to head back to the funny times of Matts Script Archive?
> has_example: Possibly useful, but poorly implemented (or possibly
> poorly documented). Most modules that include examples do so in an
> "Examples" section of the POD, not in a separate file or directory.
> The has_example documentation implies that it'll only be satisfied by
> a separate file or directory.
Can you back up the statement regarding "Most modules .. do so in an
Examples section"? If yes, I'd love to integrate the code you have
written to do so into CPANTS, to make it even better.
Having (some) examples in a seperate dir & ready to run makes it much
easier to figure out how a dist works. No cutting&pasting from POD (with
all the nice problems that might induce).
> is_prereq: Awful. I write many of my modules to without depending
> on prerequisites; this reduces the load on end-users. I expect that
> many other module authors do the same. Should I include other
> authors' modules just to improve their kwalitee scores? More
> importantly, why should Acme::FromVenus get a point for this test,
> just because the author put up a dummy distro, Acme::FromMars, which
> uses it? Some of my modules are very useful for end-users' code, not
> so much for module developers' code. So I get dinged for this?
is_prereq is an optinal metric and thus does not count for the CPANTS
game. And yes, Apps ususally won't get prerequed. Tough luck.