Bug #72043 for CPANPLUS-Dist-Build: Smoke results indicate insufficient installation of dependencies

Sun Oct 30 03:11:42 2011 ANDK [...] cpan.org - Ticket created

CC:	PHRED [...] cpan.org
Subject:	Smoke results indicate insufficient installation of dependencies

http://analysis.cpantesters.org/reports_by_field?SUBMIT_xxx=Submit&distv=WebService-Yahoo-BOSS-0.06&field=qr%3A%28Can%27t+locate+\S%2Bpm%29&field=mod%3ACPANPLUS%3A%3ADist%3A%3ABuild&field=meta%3Afrom&field=meta%3Awriter&field=mod%3AAny%3A%3AMoose&field=qr%3A%28Can%27t+locate+\S%2Bpm%29&order=1ta This table shows 131 pass reports and 54 fail reports. 53 of the fail reports are by CPANPLUS and all of them fail with the same diagnostic: Can't locate Moose.pm. There is only one report by Steven Schubiger using CPAN-Reporter-1.2002 with this profile. The distro is not to blame, it has declared dependency on Any::Moose. I see nothing wrong in Any::Moose either. When I try to install PHRED/WebService-Yahoo-BOSS-0.06.tar.gz on a fresh perl with CPAN.pm it passes its test and I find Mouse installed afterwards. The Schubiger result might be an indicator that there is some bug elsewhere but statistical evidence strongly suggests that CPANPLUS or CPANPLUS::Dist::Build have the key knowledge how it comes to this buggy results. What do you think?

Sun Nov 06 14:37:10 2011 chris [...] bingosnet.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #72043] Smoke results indicate insufficient installation of dependencies
Date:	Sun, 6 Nov 2011 19:36:55 +0000
To:	Andreas Koenig via RT <bug-CPANPLUS-Dist-Build [...] rt.cpan.org>
From:	"Chris 'BinGOs' Williams" <chris [...] bingosnet.co.uk>

On Sun, Oct 30, 2011 at 03:11:43AM -0400, Andreas Koenig via RT wrote: Show quoted text

> This table shows 131 pass reports and 54 fail reports. 53 of the fail > reports are by CPANPLUS and all of them fail with the same diagnostic: > Can't locate Moose.pm. There is only one report by Steven Schubiger > using CPAN-Reporter-1.2002 with this profile. > > The distro is not to blame, it has declared dependency on Any::Moose. I > see nothing wrong in Any::Moose either. When I try to install > PHRED/WebService-Yahoo-BOSS-0.06.tar.gz on a fresh perl with CPAN.pm it > passes its test and I find Mouse installed afterwards. > > The Schubiger result might be an indicator that there is some bug > elsewhere but statistical evidence strongly suggests that CPANPLUS or > CPANPLUS::Dist::Build have the key knowledge how it comes to this buggy > results. > > What do you think? >

Hi, Andreas, I have been Internet-less this past week on holiday so sorry for the delay in response. This is my theory of what is happening. CPANPLUS/CPANPLUS::YACSmoke use a similar mechanism to CPAN.pm's build_dir except that previously built build directories are prepended onto PERL5LIB as prereqs are resolved rather than pre-prepended up front. What I think happens is that during a particular smoke run, Any::Moose gets pulled in as prereq and Moose has already been pulled in, so Any::Moose's Makefile.PL says that it doesn't require any prereqs and any generated MYMETA.[json|yml]/Makefile (used for subsequent prereq resolution) will not have any mention of Mouse as a prereq. Next time during a smoke run that Any::Moose is pulled in as a prereq and Moose is *not* already pulled in as a prereq, Mouse will not be pulled in (as Any::Moose thought Moose was "installed" ). Mouse stopped being a hard dependency with version 0.16 of Any::Moose I note from it's Changes file ( and confirmed using the dist diff tool on metacpan ). Perhaps an explicit 'dynamic_config' => 1 should elicit rerunning of configure/prepare stage of the process (ie. rerun Makefile.PL/Build.PL). -- Chris Williams aka BinGOs PGP ID 0x4658671F http://www.gumbynet.org.uk ==========================

Download (untitled)
application/pgp-signature 189b

Message body not shown because it is not plain text.

Sun Nov 06 14:37:12 2011 The RT System itself - Status changed from 'new' to 'open'

Mon Nov 07 01:23:25 2011 ANDK [...] cpan.org - Correspondence added

But 'dynamic_config' => 1 must be the default for all toolchain implementors, or has this changed sometime? "If this field is omitted, it defaults to 1 (true)." is in the spec: http://module-build.sourceforge.net/META-spec-v1.4.html#dynamic_config Your theory sounds very plausible. In the meantime I have discovered more distributions being affected: Plack-Server-AnyEvent-Server-Starter-0.00002 WebService-Solr-0.16 AnyEvent-MPRPC-0.11 WWW-Wunderground-API-0.02 Dancer-Plugin-Bcrypt-0.4.0 Proc-Class-0.05 Net-GitHub-0.40_04 XML-Feed-Deduper-0.05

Mon Nov 07 10:54:49 2011 chris [...] bingosnet.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #72043] Smoke results indicate insufficient installation of dependencies
Date:	Mon, 7 Nov 2011 15:54:32 +0000
To:	Andreas Koenig via RT <bug-CPANPLUS-Dist-Build [...] rt.cpan.org>
From:	"Chris 'BinGOs' Williams" <chris [...] bingosnet.co.uk>

On Mon, Nov 07, 2011 at 01:23:26AM -0500, Andreas Koenig via RT wrote: Show quoted text

> Queue: CPANPLUS-Dist-Build > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=72043 > > > But 'dynamic_config' => 1 must be the default for all toolchain > implementors, or has this changed sometime? > > "If this field is omitted, it defaults to 1 (true)." is in the spec: > http://module-build.sourceforge.net/META-spec-v1.4.html#dynamic_config > > Your theory sounds very plausible. In the meantime I have discovered > more distributions being affected: >

Actually the more I thought about it the more I thought that Any::Moose is doing this slightly wonky. I've cloned the any-moose repository and made a fix: https://github.com/sartak/any-moose/pull/2 Cheers, -- Chris Williams aka BinGOs PGP ID 0x4658671F http://www.gumbynet.org.uk ==========================

Download (untitled)
application/pgp-signature 189b

Message body not shown because it is not plain text.

Mon Nov 07 11:01:46 2011 rt.cpan [...] sartak.org - Correspondence added

I applied Chris's change and released Any::Moose 0.18, for what it's worth. :)

Tue Nov 08 01:18:49 2011 ANDK [...] cpan.org - Correspondence added

Thanks to both of you for the quick workaround, but Chris, I would hope you stop caching MYMETA.{yml,json}, they are not supposed to be cached.