On Tue, Jan 08, 2008 at 01:56:48PM -0500, David Golden wrote:
> On Jan 8, 2008 1:11 PM, Barbie <[EMAIL PROTECTED]> wrote:
> > It's mostly to handle exclusions, avoid duplication, prempt NA
> > submissions (a NA prereq will submit a NA in place of a FAIL for the
> > current dist),
>
> I thought we agreed in discussing semantics about NA that
> distributions failing prereqs should not have reports submitted at
> all. (ca. CPAN::Reporter 0.46)
If the prereq has been reported as NA, then if the dist being tested
fails, that means the dist being tested is also NA. The example I had at
the time was trying to test on 5.6.1 where a dist required a module that
required 5.8, this therefore meant the dist being tested also had a NA
filed against it.
The only time it won't get an NA report is if the prereq is actually
optional and the dist passes.
Note that a FAIL prereq and a NA prereq are different things.
> > allow retesting previously halted (internal ABORT grade)
> > dists,
>
> Better abort handling should probably go into CPAN::Reporter's Todo list.
It's used by YACSmoke to prevent testing dists which have a prereq that
has previously be aborted. When I was running bulk testing, the test
runs were done overnight and could take several hours, before this check
it wasn't unusual for the run to still be running when I got in in the
morning.
> > > CPAN::Shell->test("AUTHOR/Dist-Name-0.01.tar.gz")
> >
> > That's essentially what I was planning for the bridge between YACSmoke
> > and CPAN/CPAN-Reporter. The only additional bit of code required would
> > be to feed back the grade to YACSmoke, which I haven't figured out yet.
> >
> > If you have any suggestions for feeding back the grade, let me know.
>
> That's tricky. Because of the way that CPAN.pm and CPAN::Reporter
> separate their concerns, CPAN never needs to know about the grade. It
> just stands in for the normal "make test" system() call. It could be
> patched in fairly easily, I suppose.
I wonder if simply checking the last entry of the history file would be
enough?
> The best approach is probably for CPAN::Reporter to tack it onto the
> CPAN::Distribution object:
>
> # hypothetical
> my $dist = CPAN::Shell->expandany("AUTHOR/Dist-Name-0.01.tar.gz");
> $dist->test;
> if ( $dist->{reporter_result}{grade} eq 'fail' ) ...
>
> I already have a grade of "discard" for reports that aren't sent (e.g.
> invalid prereqs). Does that seems like a workable approach?
That sounds great, exactly the sort of thing I was hoping for :)
By the sound of it your "discard" and our "abort" are the same thing, so
that shouldn't be a problem.
> If
> Andreas has no objections, that's probably as clean as it's going to
> get (short of actually writing a CPAN::Reporter::Result class that
> gives you a real API).
No, I think your first suggestion above will work perfectly :)
>
> > Also (perhaps a question for Andreas), how do I get/set configuration
> > values without commiting, so that the tester can temporary amend
> > configuration details without affecting their regular configuration?
>
> Set the "auto_commit" option to 0. Then any changes won't be committed.
It wasn't the commit part I was after, but the get/set methods for
config values.
> The history file records every result sent with grade. It's more of a
> log file than a database.
Right, understand now :)
My next challenge is to write the tests!
Cheers,
Barbie.
--
Birmingham Perl Mongers - http://birmingham.pm.org
Memoirs Of A Roadie - http://barbie.missbarbell.co.uk
