in reply to PREREQ_PM ignored by cpan-tester

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.

— Ken

Replies are listed 'Best First'.
Re^2: PREREQ_PM ignored by cpan-tester
by syphilis (Archbishop) on Feb 01, 2016 at 11:57 UTC
    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
      "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. ++

      — Ken