CPAN detergent needed

ethan on 2005-09-29T05:56:39

There were times when a pathetic addition to the CPAN was merely a minor annoyance, easy to tolerate as such a module did not interfer with one's own work.

Nowadays however, one rotten CPAN egg is capable of making tests of your own modules fail, as can be seen here and here.

Mind you, the offending module isn't used nor mentioned anywhere in the modules whose tests it can make fail. The failures happen because this pathetic piece of shit doesn't adhere to any CPAN packaging standards and its files and directories somehow get merged with those of other modules on tarball-extraction.

And now I am waiting for those who still claim that CPAN's policy should be as liberal as possible when it comes to uploads. No, it shouldn't. Instead, too obvious breaches against CPAN conventions should be denied their upload. Furthermore, those that were uploaded in the past ought to be deleted immediately.

I suppose it's not going to happen. That means that my modules will continue to fail their tests on that particular machine until its admin finally removes the offending files by hand.


at least..

domm on 2005-09-29T08:57:59

.. it got really low kwalitee :-)

What specifically?

petdance on 2005-09-29T14:31:17

What specifically do you suggest gets checked for?

And how does this module make your own tests fail? What is the harmful behavior it's causing?

Re:What specifically?

ethan on 2005-09-29T16:32:41

What specifically do you suggest gets checked for?

With respect to an uploading policy, you mean? I'd say the criterium of extracting nicely into a directory of its own is the very least that should be checked for.

And how does this module make your own tests fail? What is the harmful behavior it's causing?

The harmful behaviour is caused by this module's tarball extracing into the directory blib/. I suppose that on this machine where the POD-tests fail for two of my modules it was unpacked while being in the subdirectories created by my modules. Thus this module planted its files under blib/lib/. My POD-test checks all .pm files in this directory not expecting to find a foreign module's files there.

Potential for self defense meantime

n1vux on 2005-10-03T22:58:39

I sort of understand how the reactions against any call for setting a minimum Kwaalliittee or some other "elitist" minimal bar for sucessfull upload is treated as a Modest Proposal. But this is worth further consideration -- the very infrastructure that now makes enforcing such possible is what is making lack of it punish good module authors. The penalty for failing the grade need not be as draconian (or procrustean?) as summary deletion; the offending "module" could be relegated to BackPan, until a replacement that meets standards is uploaded.

Maybe you can have your POD-test parse your MANIFEST and only test your own files, using Test::Pod::all_pod_files_ok( @files ); . It looks like OODoc::Manifest::files() will provide a OO interface to your Test to read the Manifest and return the list needed, but warning I haven't tried it. Whether it's prerequisites are worth the bother I don't know ... how hard can parsing a MANIFEST be, he asked with trepidation.