On Jul 5, 2008, at 7:58 AM, Barbie wrote:
On Fri, Jul 04, 2008 at 10:02:24PM -0400, James E Keenan wrote:
David Cantrell wrote:
On Tue, Jun 17, 2008 at 09:40:02PM -0400, David Golden wrote:
There also seem to be some things in ~/tmp/
That's on linux. It's worse on Win32. Lots of stuff winds up
dumped
in c:\. In one case, I think there were several thousand tiny
directories.
On *nix I periodically clean out several hundred files from /tmp.
I assume that they're created by File::Temp.
In the course of my testing of Parrot's configuration and build
tools, I
have had *many* occasions to create temporary files and
directories. At
one point last year I got complaints. We found that code like
this did
the trick:
use File::Temp qw( tempdir tempfile );
my $tdir = tempdir( CLEANUP => 1 );
my ( $tmpfile, $fname ) = tempfile( UNLINK => 1 );
Since these are functions from a core module, there is no excuse
for any
CPAN author not to use them with these cleanup options. (I'd say
that
proper cleanup of temp files created during testing should be a
'kwalitee' metric -- but I don't want to get into that argument!)
Funny you should mention that. I've been slowly working through the
rewrite of YACSmoke. One of the aspects that I've been thinking
about is
having CPAN Testers run the often disputed "pod.t" and "podcover.t"
type
tests.
Yecch! I particularly dislike the pod.t and podcover.t tests. I
specifically do not include them as default selections in
ExtUtils::ModuleMaker.
[snip]
However, the major problem I can see with that is if a distribution is
well respected, but fails these tests. I can see a huge backlash.
Starting with me.
The CPAN distro of which I am most proud and for which I get the most
positive feedback is List-Compare. But for years this distro got red
marks in the CPANTS columns for those two tests. Why? Because
instead of organizing the POD with the subroutine names as "=head" or
"=item" elements, I organized it by the way humans would pose a
question, e.g., "How do I get the intersection of more than two
sets?" Those tests -- more likely podcover.t -- refused to recognize
that I had written documentation which, if printed, would run to more
than twenty pages.
Apart from these objections, to include pod.t and podcover.t in CPAN
Testers would constitute scope creep. As I see it, automated CPAN
testing exists first and foremost to provide module authors with
immediate feedback on these questions:
* Were we able to download your distro from the CPAN and prepare it
to run?
* Were we able to build it successfully with either
ExtUtils::MakeMaker or Module::Build?
* Which tests, if any, did it fail?
Now, as the point of this thread is to prevent garbage from getting
on the machines of CPAN testers, you could argue that a fourth
question should be:
* If the distro needs to clean up after itself, does it do so?
But once you start adding "kwalitee" features, you diverge from your
core mission in a misguided attempt to be all things to all people.
Please don't do it!
Thank you very much.
Jim Keenan
