* Eric Wilhelm <[EMAIL PROTECTED]> [2008-06-30 23:15]:
> # from chromatic
> # on Monday 30 June 2008 13:01:
>
> >Where CPANTS works now is identifying actual, functional
> >problems with distributions: missing licensing information,
> >not extractable, POD errors, invalid META.yml, et cetera.
>
> There is some use in that, but what is the line before "&c"?
I think there is at least one very clear line, which is to be
drawn at “will this cause problems for users who don’t even care
about the module itself and are installing it merely as a prereq
for something else?” An incorrectly packaged distro clearly will.
> It's a slippery cliff between "what works" and "what some
> people happen to think". Is in: why isn't "uses Module::Build,
> contains no Makefile.PL, and requires 5.8.8" a point?
See above.
> What about "does not include cargo-culted Test::PodCoverage or
> Test::Pod"?
These things cause problems for actual users. This should be a
metric per the above criterion. And I’m not joking.
(The problem is that one of the aspects of kwalitee was supposed
to be that the module is properly documented – regardless of how
good the documentation is, it should follow proper form, at
least. Unfortunately, since a design goal for CPANTS is not to
run any code from the distro, testing POD coverage and even POD
itself is not actually doable because you don’t know what the API
will look like at runtime (AUTOLOAD, autogenerated functions or
methods, etc etc etc). So instead of measuring whether the POD
has good coverage, CPANTS measures if it has tests to check the
POD coverage… I honestly like and respect Thomas, so I don’t want
to insult him at all, but the absurdity of this line of thought
is mindboggling. How he arrived at the conclusion that this would
provide any sort of useful data point is unfathomable to me.)
> "Has no CamelCase"?, "No methods expect ({arbitrary => extra
> => 'braces'})"?, "isa() is a method"?, "overrides can()"?, "No
> OPTIONS|AS|NUMERIC|CONSTANTS"?, "Does not use
> Class::Accessor"?, "Mutators are set_foo()"?, "Does not inherit
> Exporter"?, "META.yml includes keywords"?, "META.yml links to
> version control"?, "Uses Moose"!?
All of those are either not measurable, directly or at all, or
have significant valid exceptions. If we stick to metrics that
can be measured directly without reliance on any kind of proxy,
I think the slope won’t be nearly so slippery as you make it out
to be.
Just the fact that we disagree about a metric would be a good
indicator that it isn’t a functional CPANTS metric. Do you
disagree that a broken tarball is bad kwalitee? No? Thought so.
But *even if* the line was difficult to find, it seems to that
just because we were unable to agree exactly where it is doesn’t
imply that we’d be unable to agree when a metric is way over it.
I can’t imagine anyone ever proposing a Has No CamelCase metric
in all seriousness and without getting struck down swiftly.
> Regardless of whether the metrics are ambiguous or debatable,
> they can only be used for comparisons between modules if you
> open a new browser window/tab and manually lookup each one.
Disagree. Whether the module is packaged correctly has nothing
to do with its purpose and is a piece of information that stands
entirely on its own.
> All of it is potentially useful data to someone, but if it is
> going to be anything besides a game, it probably needs more
> ways to be queried.
Agree on that.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
