develooper Front page | perl.module-authors | Postings from June 2008

Re: Fwd: New CPANTS metrics

Thread Previous | Thread Next
From:
Thomas Klausner
Date:
June 10, 2008 11:54
Subject:
Re: Fwd: New CPANTS metrics
Message ID:
20080610185121.GA29188@d610.o.factline.com
Hi!

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?

185
http://cpants.perl.org/dist/shortcoming?metric=has_buildtool


>    has_working_buildtool: ditto

326
http://cpants.perl.org/dist/shortcoming?metric=has_working_buildtool

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.

Yeah, whatever.

>    extractable: How many CPAN modules have EVER been released with a
> weird packaging format?  Is this addressing a real problem in the
> world?

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 
birth to.

>    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
> circumstances.

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.



-- 
#!/usr/bin/perl                              http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About