Skip Menu |
 

This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics
Id: 56855
Status: open
Priority: 0/
Queue: CPAN

People
Owner: Nobody in particular
Requestors: marcoep [...] gmail.com
Cc:
AdminCc:

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



Subject: "CPAN::Shell->install('.')" vs "cpan ."
Download (untitled) / with headers
text/plain 1.6k
Hi there, It looks like that [perl] use CPAN; chdir '/path/to/decompressed/module'; CPAN::Shell->install('.'); doesn't behave the same as [bash] $ cd /path/to/decompressed/module $ cpan . Indeed: [perl] $ pwd /data/home/poleggim/tmp $ ./cpan_dot_test.pl cwd=/tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04 PWD=/tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04 CPAN::iCwd=/data/home/poleggim/tmp You are visiting the local directory '.' without lock, take care that concurrent processes do not do likewise. ... DONE Restored the state of none (in 0.9252 secs) You are visiting the local directory '/data/home/poleggim/tmp/.' As yuo can see ^^above^^, the cwd is the same as the starting directory. So basically, cpan::shells ignores $ENV{PWD} even though it uses the Cwd module as the test script. Incidentally, I found that cpan::shell uses an internal pwd -- $CPAN::iCwd, which, if properly set, makes it do the Right Thing (line #14 of cpan_dot_test.pl uncommented): $ ./cpan_dot_test.pl cwd=/tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04 PWD=/tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04 CPAN::iCwd=/tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04 You are visiting the local directory '.' without lock, take care that concurrent processes do not do likewise. ... DONE Restored the state of none (in 0.9148 secs) You are visiting the local directory '/tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04/.' without lock, take care that concurrent processes do not do likewise. Running make for /tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04/. ... Am I missing something? Cheers, Marco
Subject: cpan_dot_test.pl
Download cpan_dot_test.pl
text/x-perl 344b
#!/usr/local/bin/perl -w use strict; use warnings; use Cwd qw(getcwd chdir); use CPAN; my $mod_path = '/tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04'; chdir $mod_path or die $!;; my $cwd = getcwd; print "cwd=$cwd\n"; print "PWD=$ENV{PWD}\n"; # $CPAN::iCwd = $cwd; print "CPAN::iCwd=$CPAN::iCwd\n"; CPAN::Shell->install('.');
From: marcoep [...] gmail.com
Download (untitled) / with headers
text/plain 333b
I forgot to say: $ uname -a SunOS kappa1 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V490 $ perl -v This is perl, v5.8.7 built for sun4-solaris And cpan is configured with 'getcwd'='getcwd' (indeed CPAN::anycwd shows the correct path.) The problem might actually be with [Cwd::]chdir behaving strangely on Solaris...
Subject: Re: [rt.cpan.org #56855] "CPAN::Shell->install('.')" vs "cpan ."
Date: Sat, 24 Apr 2010 05:00:55 +0200
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Download (untitled) / with headers
text/plain 426b
Show quoted text
>>>>> On Fri, 23 Apr 2010 10:55:36 -0400, "Marco Emilio Poleggi via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> use CPAN; > chdir '/path/to/decompressed/module'; > CPAN::Shell->install('.');
Try Show quoted text
> use CPAN; > CPAN::Shell->install('/path/to/decompressed/module/.');
CPAN.pm needs to run chdir() all over the place. Maybe the chdir code parts can be insulated but it looks like quite a big endavour. -- andreas
From: marcoep [...] gmail.com
Download (untitled) / with headers
text/plain 939b
Show quoted text
> Try >
> > use CPAN; > > CPAN::Shell->install('/path/to/decompressed/module/.');
>
Yep, that works, thanks! Weird, I missed the right combination of dot and slashes during my tests ;-) But the call CPAN::Shell->install($mod_path.'/.') or die "cpan::shell failed?!"; seems to "formally" fail even if the package got make-installed correctly ... Appending installation info to /data/home/poleggim/myroot/usr/local /lib/perl5/lib/perl5/sun4-solaris/perllocal.pod /tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04/. /usr/ccs/bin/make install -- OK Directory '/tmp/O3g4WBN_IG/Catalyst-Model-DBIDM-0.04/.' not below /data/home/poleggim/.cpan/build, will not store persistent state cpan::shell failed?! at ./cpan_dot_test.pl line 22. $ echo $? 29 Surely I'm missing something again... So, what's the correct way for checking failures, a part from parsing the output of CPAN::Shell->failed? Cheers, Marco
Subject: Re: [rt.cpan.org #56855] "CPAN::Shell->install('.')" vs "cpan ."
Date: Mon, 26 Apr 2010 21:55:13 +0200
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Download (untitled) / with headers
text/plain 757b
Show quoted text
>>>>> On Mon, 26 Apr 2010 04:45:27 -0400, "Marco Emilio Poleggi via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> But the call
Show quoted text
> CPAN::Shell->install($mod_path.'/.') or die "cpan::shell failed?!";
Show quoted text
> seems to "formally" fail even if the package got make-installed correctly
Show quoted text
> Surely I'm missing something again... So, what's the correct way for > checking failures, a part from parsing the output of CPAN::Shell->failed?
From the manpage: Note that install() gives no meaningful return value. See uptodate(). I just realize that this is a bit terse, sorry for that. But basically that's it: a single return value for an install() call just doesn't cut it. Any single install can expand to arbitrary numbers of fails and successes. -- andreas
From: marcoep [...] gmail.com
Download (untitled) / with headers
text/plain 736b
Show quoted text
> From the manpage: > > Note that install() gives no meaningful return value. See > uptodate(). > > I just realize that this is a bit terse, sorry for that. But basically > that's it: a single return value for an install() call just doesn't > cut
Thanks for the information. I (lazily) missed the spot in the man page. Show quoted text
> it. Any single install can expand to arbitrary numbers of fails and > successes. >
But, IMHO, that's an interface bug: if I call foo(), it should tell me if it failed or not, then, if failed, I should be able to call bar() to know what's happened. Otherwise, an exception mechanism should be provided. Without something like that, it's very difficult to track the program execution :-( Cheers, Marco
Subject: Re: [rt.cpan.org #56855] "CPAN::Shell->install('.')" vs "cpan ."
Date: Wed, 28 Apr 2010 08:32:20 +0200
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Download (untitled) / with headers
text/plain 697b
Show quoted text
>>>>> On Tue, 27 Apr 2010 04:52:51 -0400, "Marco Emilio Poleggi via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> But, IMHO, that's an interface bug: if I call foo(), it should tell me > if it failed or not, then, if failed, I should be able to call bar() to > know what's happened.
I'm not sure if I can agree. One interface is not doing what you expect (sorry for that). But the interfaces uptodate() and failed() are there, so you can find out what happened. Show quoted text
> Otherwise, an exception mechanism should be > provided. Without something like that, it's very difficult to track the > program execution :-(
I'm open to patches that make it less difficult to program with CPAN.pm. -- andreas


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.