Re: PREREQ_PM ignored by cpan-tester
by kcott (Archbishop) on Feb 01, 2016 at 08:35 UTC
|
G'day Rob,
"What's the recommended way of avoiding such FAIL reports?"
The CPAN Testers Wiki has some information which may be relevant.
The closest I can see is "How can I stop getting FAIL reports for missing libraries or other non-Perl dependencies?" (although there may be others of interest).
I had a similar issue (i.e. questionable FAIL reports) with Tk::ROSyntaxText: testers without an X server (or equivalent) running, who would be unable to run any Tk code, were issuing FAIL reports.
My solution was to add code like this to all appropriate tests:
my $mw = eval { MainWindow->new(
-title => q{Tk::ROSyntaxText: 01.instantiate.t},
); };
if ($mw) {
plan tests => 3;
}
else {
plan skip_all => q{No display detected.};
}
[If you're interested, the Changes file has some more information about that and the MANIFEST has links to all the test code.]
While I appreciate that won't be exactly applicable to your issue, it may provide some hints with respect to a direction to take.
| [reply] [d/l] [select] |
|
|
The CPAN Testers Wiki has some information which may be relevant.
Yeah, I did skim through that document.
It tells me how to deal with *my* fuck-ups, but doesn't offer much wrt dealing with *their* fuck-ups.
I guess all one can do is contact the tester and file a bug report ... then wait for an improvement.
Ken, if I were to take a leaf out of your book I would probably begin each test script with something like:
eval {require Math::MPFR};
and then skip all tests if Math::MPFR failed to load.
That would certainly avoid the FAILs that are the subject of this thread, but it seems to me that it would also be an act of deception on my part.
I'd be getting a PASS without any of the tests actually being run - and without any guarantee that any of the tests would have passed if only Math::MPFR had been found.
For your scenario, my impression is that if an X server is needed, you should be testing for its existence in the Makefile.PL.
If it's there, than the build process (including the running of all tests) continues.
If it's not there, then the Makefile.PL does an immediate exit 0; and you end up with an NA report (or maybe no report at all).
The risk there would be that an X server is present, but the Makefile.PL fails to detect it and does the exit 0; mistakenly. That wouldn't bother the cpan-testers, though it might bother a potential user.
But giving yourself a PASS just because the X server isn't present is a bit cheeky IMHO.
Anyway - I didn't examine your scenario properly, and you probably know far better than I precisely what *you* ought to be doing :-)
Cheers, Rob
| [reply] [d/l] [select] |
|
|
"But giving yourself a PASS just because the X server isn't present is a bit cheeky IMHO."
I don't really disagree with this.
On the other hand, getting a FAIL "just because the X server isn't present" doesn't present potential users of the module with a realistic report either.
Anyway, in the CPAN Testers Wiki, that's the documented way to do it. Here's what it says:
"Why are you testing (and failing) my Tk-ish module without an X server?"
Until very recently, Tk wouldn't build without a display. As a result, the testing software would look at the test failures for your module and think "ah well, one of his pre-requisites failed to build, so it's not his fault" and throw the report away. The most recent versions of Tk, however, *will* build without a display - it just skips all the tests. So the testing software sees that it passed, and thinks there must be something wrong with your module. You should check for a working Tk (and hence X11) environment by checking if MainWindow->new() throws an exception:
my $mw = eval { MainWindow->new };
if (!$mw) { ... skip tests ... }
For what it's worth, the first test (00.load.t) doesn't have the X server test and prerequisites are checked there. Obviously, that doesn't test functionality.
In closing, thanks for taking the time to post your thoughts on this.
++
| [reply] [d/l] [select] |
Re: PREREQ_PM ignored by cpan-tester
by Anonymous Monk on Jan 31, 2016 at 09:59 UTC
|
Is there something else I'm supposed to do ? Ignore it?
What's the recommended way of avoiding such FAIL reports ? Ignore it, its unavoidable?
Ok, enough quasi jokes
One easy suggestion to make, contact those testers directly to do some digging, like for example, provide the output that comes before make test
| [reply] |
|
|
Ignore it?
Yes, I do try to ignore false FAILs - but sometimes they get the better of me.
The number of these FAILs is now 4 (all from the same tester).
If he decides to test 20 different perl configurations then I'll end up with 20 FAILs - which is even harder to ignore.
If there's no suitable workaround that I can implement to circumvent these particular FAILs, then that makes them even more insidious.
The tester in this particular case is Peter Acklam. He has been responsive in the past, so I've notified him of the problem.
I also get other occasional false FAILS as a result of a different issue affecting only App::cpanminus::reporter, as far as I know.
For example see:
http://www.cpantesters.org/cpan/report/78ab4860-c608-11e5-9eb0-875dfcf88752
http://www.cpantesters.org/cpan/report/7955d258-c608-11e5-9eb0-875dfcf88752
http://www.cpantesters.org/cpan/report/7a4a4ad6-c608-11e5-9eb0-875dfcf88752
All of those fail to compile, and should therefore report UNKNOWN. But they come back as FAIL.
Annoying as those ones are I at least can provide a workaround for
them if I think it's worth the effort .... and worth the risk of getting the workaround wrong :-(
Cheers, Rob
| [reply] |
|
|
The tester in this particular case is Peter Acklam. He has been responsive in the past, so I've notified him of the problem.
Peter noticed that the false FAIL reports were specific to perl-5.14.x, and that the problem vanished if EU-MM was updated to version 6.58.
The next release of Math::MPC will therefore specify EU-MM-6.58 as a PREREQ_PM, which should avoid these FAILs.
There's nothing in the Math::MPC distro that actually needs version 6.58 or later, so this change is made solely for the purpose of avoiding a CPAN::Reporter bug. (I hope it doesn't inconvenience someone who is actually wanting to use Math::MPC ... I think that's unlikely.)
The FAIL count because of this single issue has now risen to 42.
Cheers, Rob
| [reply] |
|
|
|
|
| [reply] |