For years I have used an absolutely stock CPAN::Mini setup to create and update a minicpan repository on a succession of laptops. That worked quite well, particularly with respect to development and testing of search.cpan.org/dist/CPAN-Mini-Visit-....
Now I'm in a position where, on behalf of Perl 5 Porters, I am examining the relationship between Perl 5 blead and the latest versions of CPAN distributions. For that purpose, CPAN-Mini's default setting of "retain the last version of a distro for each author doing a release" results in many different versions of distros such as DBIx-Class which have had different releasors over the years.
So I'm now going to try CPAN-Mini-LatestDistVersion and have added that as the value for 'class' in my .minicpanrc file. As I type, I'm populating a new minicpan repository. The acid test will come when I type 'minicpan' to update the repository and some distro has had a new release from a different releasor.
This distribution comes with no test suite -- just the one default test.pl file that you would get with an old version of h2xs. Hence, it is impossible to run coverage analysis and get an idea as to where bugs might be lurking. (I have not yet tried its functionality.)
I have used File::Temp extensively in the test suites of my CPAN modules ExtUtils::ModuleMaker and ExtUtils::ModuleMaker::PBP and will use it directly in a module to come, File::Save::Home. I strongly advocate its use in any situation where you are testing code for the creation of files and directories. All such tests should take place in a temporary directory functioning as a sandbox, and that temporary directory and its contents should be removed when the test has been completed.
My only quibble with File::Temp is that, having used the object-oriented interface and gotten accustomed to having my tempfiles be deleted when the object goes out of scope, I long for the same facility with respect to tempdirs. As of v0.16, 'tempdir' is available only through the functional interface and you must explicitly call CLEANUP => 1 to get the tempdirs so created deleted at the end of the *program*. I would love to have a function/method that automatically deletes tempdirs at the end of their *enclosing scope/block*. This would, for example, enable me to create a tempdir within a block, test for its existence, have the tempdir deleted automatically when the block is closed, then test again for its non-existence.
This wish aside, kudos to Tim Jenness for both writing File::Temp and, even more importantly, maintaining it over the years.
Although I heard Geoff Avery's presentation on ExtUtils::ModuleMaker at YAPC::NA::2003 in Boca Raton (and possibly also in Paris), I never got around to installing it until today, when I decided to play around with the 'modulemaker' utility as an alternative to 'h2xs'.
Geoff, I have to pay you a high compliment: 'modulemaker' is truly f***ing Lazy!
I do have some criticisms, but to those in a moment. First, some context. I'm planning to give a talk on Perl modules and testing in a couple of months. As part of the talk, I want people in the audience to create a Perl module from scratch as I speak.
At first I thought: One step in the process will be to teach them about h2xs. But that will entail teaching them to set aside h2xs's original purpose (facilitating inclusion of C code in a Perl extension) and focus on what is probably its more widely used purpose: creating the initial structure for modules with no C code whatsoever. That meant that (a) I had to study the h2xs docs much more than previously; (b) I had to try out the most recent version (since I haven't had to create a module structure totally from scratch in years). When I tried it out, this was the Makefile.PL I got:
($] >= 5.005 ? ## Add these new keywords supported since 5.005
(ABSTRACT_FROM => 'lib/Nola/Three.pm', # retrieve abstract from module
AUTHOR => 'James E Keenan <jimk@local>') : ()),
I gagged at this. It's much uglier than its output of 3 or so years ago. It took me 8 or 10 viewings to realize that the 3 lines below PREREQ_PM are (take a deep breath) the evaluation of a ternary condition within the list of arguments being passed to WriteMakefile()! And, of course, it gets the e-mail address wrong.
So, I thought, maybe is the time for me to get familiar with EU::MM. But, I figured that for purposes of my talk, what I really needed to do was to get familiar with the 'modulemaker' command-line utility -- since *that* is what is really the drop-in replacement for 'h2xs'.
So that's what I did at work today! And as I filled in the responses to the prompts I thought: Wow, this is really f***in' Lazy! I could have my secretary do it!
Now the criticisms -- and, with one exception, these are criticisms of the utility, not of the module (which I haven't really peered into or used in a script).
(1) The Makefile.PL created by modulemaker indicates Test::Simple is needed:
But the test file created by the same process uses Test::More, not Test::Simple:
use Test::More tests => 2;
What gives? Shouldn't it be Test::More which is specified in PREREQ_PM?
(2) As you can see above, the Makefile.PL created by modulemaker includes a line for the ABSTRACT. But, AFAICT, modulemaker doesn't prompt the user to enter an abstract. I would suspect that you could add this rather easily, and it would avoid POD looking like this:
The neat thing about the modulemaker utility is that if you follow the prompts you can create a module *that does absolutely nothing* and have it go through make, make test, make install and make dist *without writing any Perl code at all*.
Now, if that ain't Laziness, I don't know what is.
My one criticism: the module could use more documentation.