Bug #53305 for cpan-script: bad prerequisite handling from command line

Sat Jan 02 20:12:48 2010 zefram [...] fysh.org - Ticket created

Subject:	bad prerequisite handling from command line
Date:	Sun, 3 Jan 2010 01:12:17 +0000
To:	bug-CPAN [...] rt.cpan.org
From:	Zefram <zefram [...] fysh.org>

Using CPAN 1.945301, from a nearly-fresh 5.11.3 core installation, I'm seeing faulty dependency following when installing from the cpan(1) command line, but correct dependency following inside the CPAN shell. The YAML and YAML::Tiny modules are both installed, to support META.yml processing. As a test case, I'm requesting installation of my module Array::Base, which depends on Lexical::SealRequireHints; the dependency is declared in the usual manner. Doing "cpan Array::Base" yields this sequence of events: 0. configure Array::Base, which reports that Lexical::SealRequireHints is not installed 1. build Array::Base (successfully) 2. test Array::Base, with most tests failing 3. install Array::Base 4. configure Lexical::SealRequireHints 5. build Lexical::SealRequireHints 6. test Lexical::SealRequireHints, passing 7. install Lexical::SealRequireHints The end result is correct: both modules are installed and both work. But if the process is interrupted in the middle then the result is not correct: a broken installation of Array::Base, with Lexical::SealRequireHints not installed. Since Array::Base was installed without ever passing its test suite, presumably it would still have been installed if there were test failures for other reasons. Doing "install Array::Base" from inside the CPAN shell yields the expected sequence: 0. configure Array::Base, which reports that Lexical::SealRequireHints is not installed 1. configure Lexical::SealRequireHints 2. build Lexical::SealRequireHints 3. test Lexical::SealRequireHints, passing 4. install Lexical::SealRequireHints 5. build Array::Base 6. test Array::Base, passing 7. install Array::Base Don't know what happens if a test suite fails from inside the CPAN shell. Output of both sequences (on separate 5.11.3 installations) is attached. -zefram

Message body is not shown because sender requested not to inline it.

Sun Jan 03 11:00:22 2010 ANDK [...] cpan.org - Correspondence added

I can confirm the behaviour you describe. I'll change the queue for the ticket hoping Brian will recognize the problem.

Sun Jan 03 11:00:24 2010 The RT System itself - Status changed from 'new' to 'open'

Sun Jan 03 11:00:53 2010 ANDK [...] cpan.org - Queue changed from CPAN to cpan-script

Mon Jan 04 16:01:40 2010 ANDK [...] cpan.org - Correspondence added

Subject:

[ping] bad prerequisite handling from command line

brian, did you receive the ticket?

Thu Jan 07 17:43:30 2010 bdfoy [...] cpan.org - Correspondence added

I have no idea what is going on there. Basically, cpan is just going to pass the module to CPAN::Shell->install. I'll try it when I get a chance to see if I can spot anything.

Tue Jan 12 17:17:18 2010 ANDK [...] cpan.org - Correspondence added

Out of curiosity I reverted the large patch f51f904ea0fb02e436d6af85e36535e57edc2d26 and the bug described by Zefram went away. I have no idea what the implications are but all tests pass so I'm tempted to make a release of current github state before Thursday. Please CC me if your answer, I'm not automatically CC'd.

Wed Jan 13 21:07:17 2010 bdfoy [...] cpan.org - Correspondence added

RT-Send-CC:

andk [...] cpan.org

On Tue Jan 12 17:17:18 2010, ANDK wrote: Show quoted text

> Out of curiosity I reverted the large patch > f51f904ea0fb02e436d6af85e36535e57edc2d26 > and the bug described by Zefram went away. > > I have no idea what the implications are but all tests pass so I'm > tempted to make a release of current github state before Thursday.

On my machine, I tracked this down to a call to CPAN::HandleConfig. If I pass the 'be_silent' argument, everything gets screwed up. If I don't, it doesn't. I went back and forth several times to verify the behavior (and having perl under git control and using `git clean -d -f` was a quick way to undo everything from the previous run). It's very late now so I'm off to bed. I suspect be_silent wasn't a good thing for me to use and I guess I can live without it. All it does is set $CPAN::Be_Silent, and only print_ornamented cares about that. It does get passed to CPAN::FirstTime::init, but that subroutine doesn't appear to care. See if commenting out this line in App/Cpan.pm fixes it for you. # App/Cpan.pm sub _process_setup_options { my( $class, $options ) = @_; ... else { # this is what CPAN.pm would do otherwise $logger->debug( "Loading normal config\n" ); CPAN::HandleConfig->load( # be_silent => 1, # now it works - CHANGE THIS LINE write_file => 0, ); $logger->debug( "Loaded normal config\n" ); } ... }

Thu Jan 14 03:03:07 2010 andreas.koenig.7os6VVqR [...] franz.ak.mind.de - Correspondence added

CC:	andk [...] cpan.org
Subject:	Re: [rt.cpan.org #53305] bad prerequisite handling from command line
Date:	Thu, 14 Jan 2010 09:02:43 +0100
To:	bug-cpan-script [...] rt.cpan.org
From:	andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)

Show quoted text

>>>>> On Wed, 13 Jan 2010 21:07:19 -0500, "brian d foy via RT" <bug-cpan-script@rt.cpan.org> said:

Show quoted text

> If I pass the 'be_silent' argument, everything gets screwed up.

Yes, it should be ripped out. It has unclear provenience and unknown intent. I cannot recollect how it emerged and the repo doesn't tell me enough. Show quoted text

> See if commenting out this line in App/Cpan.pm fixes it for you.

Yes, it does. Thank you very, very much. I have reintegrated your patch, += 0.0001 on the $App::Cpan::VERSION and made a release 1.94_54. -- andreas