Skip Menu |
 

This queue is for tickets about the CPANPLUS-Dist-Build CPAN distribution.

Report information
The Basics
Id: 72043
Status: open
Priority: 0/
Queue: CPANPLUS-Dist-Build

People
Owner: Nobody in particular
Requestors: ANDK [...] cpan.org
Cc: PHRED [...] cpan.org
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.58
Fixed in: (no value)



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?
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>
Download (untitled) / with headers
text/plain 2.1k
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.

Download (untitled) / with headers
text/plain 552b
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
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>
Download (untitled) / with headers
text/plain 863b
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.

I applied Chris's change and released Any::Moose 0.18, for what it's worth. :)
Download (untitled) / with headers
text/plain 143b
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.