Class::MOP version 0.94 required--this is only version 0.88

[Andreas J. Koenig]

Whoa there,

I cannot understand what's the history of this tester's perl. But it has
happened on more than one setup that test on a module yield a FAIL due
to some dependency chain combined with some history of this perl
installation (or so it seems).

http://nntp.x.perl.org/group/perl.cpan.testers/5691464
http://nntp.x.perl.org/group/perl.cpan.testers/5671218
http://nntp.x.perl.org/group/perl.cpan.testers/5669841

We don't know which version of Moose was running there because Moose is
not declared prereq thus not reported. But we know that this Moose had a
prereq of Class::MOP 0.94 and nonetheless Class::MOP 0.88 was installed.
How come?

Your intuition appreciated. I have seen dozens reports with this failure
mode and they all look bogus to me and I cannot pin down what goes
wrong.

Thanks,
--
andreas

[Serguei Trouchelle]

Andreas J. Koenig wrote:

> I cannot understand what's the history of this tester's perl. But it has
> happened on more than one setup that test on a module yield a FAIL due
> to some dependency chain combined with some history of this perl
> installation (or so it seems).
>
> http://nntp.x.perl.org/group/perl.cpan.testers/5691464
> http://nntp.x.perl.org/group/perl.cpan.testers/5671218
> http://nntp.x.perl.org/group/perl.cpan.testers/5669841
>
> We don't know which version of Moose was running there because Moose is
> not declared prereq thus not reported. But we know that this Moose had a
> prereq of Class::MOP 0.94 and nonetheless Class::MOP 0.88 was installed.
> How come?

Just took a look at my environment. Class::MOP is 0.88 and Moose is 0.92.
I suppose it may be a problem with CPAN::Reporter::Smoker's "install" feature.

When Moose 0.92 is tested by CPAN, it loads Class::MOP 0.94 to PERL5LIB, then (I suggest, didn't check it myself!)
Moose gets installed while Class::MOP stays in cpan/build directory.

Just a suggestion. If Dan uses 'start("install" => 1)' too, it can be a reason for this strange behaviour.

Will take a closer look at it when time permitted.

> Your intuition appreciated. I have seen dozens reports with this failure
> mode and they all look bogus to me and I cannot pin down what goes
> wrong.

--
Serguei Trouchelle

[Serguei Trouchelle]

I've just looked at smoker window, and wow! Just in time!

Smoker: testing Class-MOP-0.82 [3760/19182] at Thu Oct 22 11:21:21 2009

Yes, it's a problem with 'install', but not in the way I thought.
Why does C:R:Smoker wants to test older version of module? Class::MOP 0.94 was already tested and installed in the
system, so testing 0.82 makes no sense.

[David Golden]

On Thu, Oct 22, 2009 at 4:34 AM, Serguei Trouchelle <st...@cpan.org> wrote:
> I've just looked at smoker window, and wow!  Just in time!
>
> Smoker: testing Class-MOP-0.82 [3760/19182] at Thu Oct 22 11:21:21 2009
>
> Yes, it's a problem with 'install', but not in the way I thought.
> Why does C:R:Smoker wants to test older version of module? Class::MOP 0.94
> was already tested and installed in the system, so testing 0.82 makes no
> sense.

C::R::Smoker tests everything in 02packages -- if you removed or
renamed modules but they are still indexed against old packages, they
still show up in 02packages. If anything ever listed such a module as
'requires' then CPAN/CPANPLUS would attempt an install of the old
distribution, so that is why it gets tested.

In this case:

Class::MOP::Class::Immutable 0.04 S/ST/STEVAN/Class-MOP-0.36.tar.gz
Class::MOP::Class::Immutable::Class::MOP::Class 0.88
D/DR/DROLSKY/Class-MOP-0.88.tar.gz
Class::MOP::Immutable 0.82 D/DR/DROLSKY/Class-MOP-0.82.tar.gz

I'm sure there's some way to get PAUSE to remove those from the index,
but I don't know off the top of my head.

-- David

[Serguei Trouchelle]

David Golden wrote:

> C::R::Smoker tests everything in 02packages -- if you removed or
> renamed modules but they are still indexed against old packages, they
> still show up in 02packages. If anything ever listed such a module as
> 'requires' then CPAN/CPANPLUS would attempt an install of the old
> distribution, so that is why it gets tested.

Is it possible to run smoke tests in reverse order -- from the oldest to newer modules?
It should help to avoid such things a little.

--
Serguei Trouchelle

[David Golden]

Since CPAN::Reporter::Smoker runs *everything*, starting from oldest
would mean 17,000 or so dists to test before it gets to anything new,
which isn't ideal for helping to test new uploads.

The C::R::S loop is "test from newest to oldest, skipping anything
we've already done, and restarting every so often to start again with
new uploads".

I'm open to a patch that does something more nuanced that one could
turn on with a parameter to the start() command.

git://github.com/dagolden/cpan-reporter-smoker.git

-- David

[Barbie]

On Thu, Oct 22, 2009 at 03:50:19PM +0300, Serguei Trouchelle wrote:

> Is it possible to run smoke tests in reverse order -- from the oldest
> to newer modules?

And what exactly would be the point of sending an author reams of fail
reports, when the latest passes and fixes all the bug they already know
about?

Generating reports for distributions, when a more recent already passes
just generates noise and gives a false impression. Newest to oldest
versions of a distribution should be the only way to smoke test,
stopping when you get a pass.

Cheers,
Barbie.
--
Birmingham Perl Mongers <http://birmingham.pm.org>
Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
CPAN Testers Blog <http://blog.cpantesters.org>
YAPC Conference Surveys <http://yapc-surveys.org>

[David Golden]

On Thu, Oct 22, 2009 at 10:55 AM, Barbie <bar...@missbarbell.co.uk> wrote:
> And what exactly would be the point of sending an author reams of fail
> reports, when the latest passes and fixes all the bug they already know
> about?

To clarify -- this is a case where a module is removed/renamed from
the "latest" distribution but is still indexed in 02packages.

For example, Class::MOP::Immutable was removed in 0.82_01, but it is
still in the 02packages file pointing to Class-MOP-0.82. Any
distribution that 'requires' Class::MOP::Immutable will trigger the
installation of Class-MOP-0.82 (DOWNGRADING any existing Class-MOP,
btw).

Thus, since Class-MOP-0.82 is addressable via 02packages, it gets smoked.

You can search on search.cpan.org for "Class::MOP::Immutable" and it
will show up. This is the same thing. Until it is removed from
02packages, it's a "live" distribution. In my opinion, anything
"live" should be smoke tested.

-- David

[Andreas J. Koenig]

>>>>> On Thu, 22 Oct 2009 07:36:11 -0400, David Golden <xda...@gmail.com> said:

> Class::MOP::Class::Immutable 0.04 S/ST/STEVAN/Class-MOP-0.36.tar.gz
> Class::MOP::Class::Immutable::Class::MOP::Class 0.88
> D/DR/DROLSKY/Class-MOP-0.88.tar.gz
> Class::MOP::Immutable 0.82 D/DR/DROLSKY/Class-MOP-0.82.tar.gz

> I'm sure there's some way to get PAUSE to remove those from the index,
> but I don't know off the top of my head.

Yes, this can be done on pause under the menu item "Reset Version". But
the problem is that it may cost months of testing until we discover such
a disturbing distro and then it needs manual intervention to get rid of
it. And all this only happens if somebody pays close attention. And in
the wirst case they leave tons of disturbing reports behind that nobody
is able to clean up.

So I'd like to propose a different approach. Something like this (off
the top of my head):

for $distro (@all_distros_from_newest_to_oldest){
$di = CPAN::DistnameInfo->new($distro);
$dist = $di->dist;
next if $seen{$dist}++;
...
}

In other words: when the older distro has the same "dist" according to
the rules of CPAN::DistnameInfo, then it is skipped. That is rather
err-on-the-cautious-side than err-on-the-risky-side. This may lead to
too few reports in some cases but that's something that can be
compensated more easily by other strategies.

What do you think? Is this even a viable option?

--
andreas

[David Golden]

On Thu, Oct 22, 2009 at 2:06 PM, Andreas J. Koenig

> In other words: when the older distro has the same "dist" according to
> the rules of CPAN::DistnameInfo, then it is skipped. That is rather
> err-on-the-cautious-side than err-on-the-risky-side. This may lead to
> too few reports in some cases but that's something that can be
> compensated more easily by other strategies.
>
> What do you think? Is this even a viable option?

I think so. Not quite like that, but conceptually. Something similar
already happens to decide whether dists with development versions
should be smoked and the rule is that the dist name (excluding the
author prefix and version) must match a dist name already in the 02
packages file.

David

[Barbie]

On Thu, Oct 22, 2009 at 08:06:07PM +0200, Andreas J. Koenig wrote:
>
> And in
> the wirst case they leave tons of disturbing reports behind that nobody
> is able to clean up.

There is a plan for that, which should hopefully be ready to be unveiled
within the next few months :)