On Mon Mar 05 11:45:29 2007, ANDK wrote:
Show quoted text
> I asked Prof Warnock about his opinion and he said I should simply set
> PERL5_CPANPLUS_IS_RUNNING. What Du you think?
>
> For CPAN.pm users this is quite a critical bug because everything goes
> wrong as soon as Autoinstall sends CPAN.pm into recursion and the next
> process starts to ask the same questions, fails at the same
> prerequisites, starts cleaning up the build directory. etc.
>
> I have the impression more and more people are using Autoinstall ... so
> what are the plans for this?
Unfortunately, your changes to CPAN.pm are now a problem for CPAN.pm
users, at least those of us who expect to be able to test for a modern
version of CPAN.pm - any autoinstall-using Makefile.PL that does a
requires onto anything that loads CPAN.pm is now broken, since the
version checks load CPAN.pm and the autoinstall process then believes
that CPANPLUS is already running and as such it shouldn't be doing anything.
This is a potentially huge problem from my POV since a lot of Catalyst
deployment setups prereq in recent CPAN.pms in order to make their
build/install scripts work sensibly, and the installdeps make target on
all of these now breaks.
Horrible though it is, the only thing I can think of that will avoid
this without re-introducing the bug is to check if Module::Install is
already loaded and not set the env var if so. I'm currently adding the
following stanza -
my $no_cpanplus_env = !exists $ENV{PERL5_CPANPLUS_IS_RUNNING};
require CPAN;
delete $ENV{PERL5_CPANPLUS_IS_RUNNING} if $no_cpanplus_env;
to work around the problem but it really doesn't seem like the right
solution to need to layer a workaround on top of your workaround.