| Subject: | App::Cpan->run() fails if you chdir after the use |
| Date: | Fri, 26 Jul 2013 11:13:54 -0500 |
| To: | bug-CPAN [...] rt.cpan.org |
| From: | Jeff Holt <jeff.holt [...] method-r.com> |
I have a need to build modules of indeterminate type (MM or MB) and it
seems reasonable to use "cpan -ft ." to do so. The pod for App::Cpan
declares no constraints upon the caller except, by inference, that @ARGV
must be set properly before calling App::Cpan->run().
The problem I have is that I want to make many modules in the same
execution. So, one should expect the code to look something like this:
use App::Cpan;
for (@modules) {
chdir($_);
App::Cpan->run("-t", ".");
}
Well, that doesn't work because I get a cpan> prompt. I had to reread the
pod to figure out that run (and its descendants) use @ARGV. Really? Ok,
I'll do the un-perly thing to move forward.
use App::Cpan;
for (@modules) {
chdir($_);
@ARGV = qw(-t .);
App::Cpan->run();
}
Well, that still doesn't work because it thinks the "working directory" is
the current directory at the time of the "use". I had to reread the CPAN.pm
code to figure out that it sets a global variable $CPAN::iCwd to the
current working directory at BEGIN time. Really? Ok, I'll do the un-perly
thing to move forward.
Here's the code that finally works. But I haven't read ALL the code to know
if it will always work. That's what bothers me the most.
use App::Cpan;
use Cwd;
for (@modules) {
chdir($_);
@ARGV = qw(-t .);
$CPAN::iCwd = cwd;
App::Cpan->run();
}
I have no idea why CPAN.pm and its indirect (direct?) caller App::Cpan do
it the way they do. But it doesn't smell very good. Sorry for the bluntness
but I don't think my comments are out of line given the workaround and the
hack that I've had to employ.
If you believe that these two idiosyncrasies are legitimate bugs, let me
know and I'll spend an hour to estimate the work required to provide a fix.