All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)
Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
More CPAN Hell
Here's my Build.PL script from Data::Record:
#!/usr/bin/perl -w
use strict;
use Module::Build;
my $builder = Module::Build->new(
module_name => 'Data::Record',
license => 'perl',
dist_author => 'Curtis "Ovid" Poe <moc.oohay@eop_divo_sitruc>',
dist_version_from => 'lib/Data/Record.pm',
requires => {
'Sub::Uplevel' => 0.09,
},
build_requires => {
'Test::Exception' => 0.21,
'Test::More' => 0.6,
},
add_to_cleanup => ['Data-Record-*'],
create_makefile_pl => 'traditional',
);
$builder->create_build_script();
See anything strange about it? Probably not. You probably aren't familiar with this module or its internals so you wouldn't know that it does not use Sub::Uplevel. Why do I include that? Because I am sick and tired of my modules failing tests because it's not there. You see, earlier versions of Test::Exception used to list Sub::Uplevel in the "build_requires" section of Build.PL. A bug in either Module::Build or CPANPLUS caused this dependency to not be picked up and tests would fail.
The latest versions of Test::Exception's Build.PL script have everything in the "requires" section to get around this. Still, despite this change having been made, my requiring this version of Test::Exception and me explicitly listing Sub::Uplevel as a requirement, I still have a reported failure for Data::Record. It appears to be related to Sub::Uplevel not being found but I can't tell and I've no idea what, if anything, to fix. I suspect this is not my fault.
Wait, it gets worse! The latest problem is five reported failures in my AI::NeuralNet::Simple module. It's a simple module, but it's my first module with C code and as such, it's a point of pride. The previous version has a failure reported because
I used to be proud of the fact that none of my modules failed their tests. Today, I get plenty of failures. Maybe they're from Module::Build, maybe they're from CPANPLUS, sometimes they're from obscure bugs with Scalar::Util on certain versions of Perl. Rarely do I get failures that I caused. This is frustrating to put so much work into open-source only to see this.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Color me grumpy... (Score:2)
-sam
Just forget about the test reports (Score:1)
Re:Just forget about the test reports (Score:2)
That sounds nice, but false negatives are as bad as false positives. People either have to dig in and find out if it's really a failure or they learn to ignore failures, force the install and then complain when the module doesn't work. It's very important that this issue get resolved.
Of course, there's yet another class of folks: those who won't install anything with test failures reported. If I have a choice amongst several modules, I don't want to dig through all of the test reports. As a result, I'
Re:Just forget about the test reports (Score:1)
Re:Just forget about the test reports (Score:2)
So are you suggesting that having useful test reports is not a worthwhile goal? I don't think you are.
Re:Just forget about the test reports (Score:1)
Is that what it is? (Score:2)
Before your explanation, I was thinking it was your email address - maybe the dist_author was being parsed for valid email address.
- Jason
Time ti become a switcher? (Score:1)
Dunno how it handles C though
Some good news :-) (Score:1)
Your problem's mostly my fault for putting out in incorrect Build.PL in the first place - sorry.
I suspect your other problem is caused by CPANPLUS ignoring build_requires (which I