Skip Menu |
 

This queue is for tickets about the Module-Install CPAN distribution.

Report information
The Basics
Id: 23735
Status: open
Priority: 0/
Queue: Module-Install

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

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



Subject: Patch against CPAN.pm batch jobs going into recursion
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Type: text/plain; charset="utf8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 452
Download (untitled) / with headers
text/plain 452b
M:I tries to detect if it is running under CPAN.pm by looking for a lock file. But there are circumstances when this goes wrong: when the user sets a different cpan HOME directory and when CPAN.pm is run in batch mode. CPAN.pm will be setting the environment variable PERL5_CPAN_IS_RUNNING and I have a patch to teach M:I using it (without breaking current heuristic). The patch is on CPAN in ANDK/patches/Module-Install-0.64-ANDK-01.patch Thanks!
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-24510-1173113129-45.23735-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 481
Download (untitled) / with headers
text/plain 481b
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?
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-24510-1173175034-1796.23735-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 528
Download (untitled) / with headers
text/plain 528b
Actually, PERL5_CPANPLUS_IS_RUNNING has turned out to be almost entirely useless. Instead, CPANPLUS is moving to the new PERL5_CPANPLUS_IS_EXECUTING environment variable, which contains the rel2abs of the Makefile.PL or Build.PL. In the CPAN.pm case. you should set PERL5_CPAN_IS_EXECUTING to the rel2abs of the Makefile.PL. This will 1) Allow new version of Module::Install to detect the presense of a parent CPAN.pm correctly 2) Allow CPAN.pm to detect that it has been invoked recursively, and handle that (right)? Adam K
MIME-Version: 1.0
In-Reply-To: <rt-3.6.HEAD-24510-1173113129-45.23735-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
References: <rt-3.6.HEAD-24510-1173113129-45.23735-0-0 [...] rt.cpan.org>
Message-Id: <rt-3.6.HEAD-24516-1173261382-1476.23735-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
From: KANE [...] cpan.org
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 910
Download (untitled) / with headers
text/plain 910b
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?
Argh, please no, don't do that. From the docs of CPANPLUS::Backend: ENVIRONMENT When "CPANPLUS::Backend" is loaded, which is necessary for just about every <CPANPLUS> operation, the environment variable "PERL5_CPAN- PLUS_IS_RUNNING" is set to the current process id. This information might be useful somehow to spawned processes. This is what that ENV var promises. 1.88_78 now sets it blindly. CPANPLUS may not even be on the box. It certainly may not be running, and you're setting it to '1' which is certainly not the process id... And you *certainly* don't want to 'kill -9' that to stop CPANPLUS... Please don't set ENV vars that aren't owned by your module -- it'll do more damage than good. Thanks, Jos
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-9082-1187498829-461.23735-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 124
Download (untitled) / with headers
text/plain 124b
Ping! Andres, I think Adam and Kane's comments happened during the RT email blackout. You should read them if you haven't.
CC: ANDK [...] cpan.org, KANE [...] cpan.org, ADAMK [...] cpan.org
MIME-Version: 1.0
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
X-Authentication-Warning: k75.linux.bogus: k set sender to andreas.koenig.7os6VVqR [...] franz.ak.mind.de using -f
In-Reply-To: <rt-3.6.HEAD-9082-1187498829-461.23735-6-0 [...] rt.cpan.org> (Michael G. Schwern via's message of "Sun\, 19 Aug 2007 00\:47\:14 -0400")
References: <RT-Ticket-23735 [...] rt.cpan.org> <rt-3.6.HEAD-9082-1187498829-461.23735-6-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: us-ascii
Received: from la.mx.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id B9ED84D8042 for <bug-Module-Install [...] rt.cpan.org>; Thu, 23 Aug 2007 01:54:06 -0400 (EDT)
Received: (qmail 5196 invoked by alias); 23 Aug 2007 05:54:05 -0000
Received: from franz.ak.mind.de (HELO franz.ak.mind.de) (212.42.235.66) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Wed, 22 Aug 2007 22:53:51 -0700
Received: from k75.linux.bogus (localhost.localdomain [127.0.0.1]) by franz.ak.mind.de (8.13.8/8.14.1/Debian-8) with ESMTP id l7N5rBdt024146; Thu, 23 Aug 2007 07:53:11 +0200
Received: (from k [...] localhost) by k75.linux.bogus (8.13.8/8.13.8/Submit) id l7N5rBGu024145; Thu, 23 Aug 2007 07:53:11 +0200
Delivered-To: cpan-bug+module-install [...] diesel.bestpractical.com
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Subject: Re: [rt.cpan.org #23735] Patch against CPAN.pm batch jobs going into recursion
Return-Path: <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: bug-Module-Install [...] rt.cpan.org
Date: Thu, 23 Aug 2007 07:53:11 +0200
Message-Id: <873ayassoo.fsf [...] k75.linux.bogus>
To: bug-Module-Install [...] rt.cpan.org
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
X-RT-Original-Encoding: utf-8
RT-Message-ID: <rt-3.6.HEAD-14661-1187848451-962.23735-0-0 [...] rt.cpan.org>
Content-Length: 1335
Download (untitled) / with headers
text/plain 1.3k
Show quoted text
>>>>> On Sun, 19 Aug 2007 00:47:14 -0400, "Michael G Schwern via RT" <bug-Module-Install@rt.cpan.org> said:
Show quoted text
> Andres, I think Adam and Kane's comments happened during the RT email > blackout. You should read them if you haven't.
Thanks Schwern! Indeed I did not receive these postings as mail. I'm sorry that I dispropriated PERL5_CPANPLUS_IS_RUNNING. This decision wasn't done lightly. I waited for 6 months to get this desastrous bug in Module::Install addressed and the only way to fix it was setting this environment variable. Due to the nature of Module::Install it is *never* upgraded, so this particular bug will stay around forever. I changed my code now so that the variable is set to $$. I fear I cannot stop using it for the time being. Maybe all parties should agree on considering this variable being burnt by wrong usage. Please deprecate it. I have not yet fully understood the advice from Adam. Can this find its way into the Module::Install docs? Maybe with coding guidelines how I'm consided to use this variable? I hope this desaster makes it clear that none of us can solve this kind of problems alone. For me it makes no sense why we need 4 environment variables to stop one builder/installer from going wild but if you can paint the bigger picture, I'll be glad to follow your lead. Thanks, -- andreas
MIME-Version: 1.0
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VERIFIED,DK_SIGNED,HTML_MESSAGE,SPF_PASS
In-Reply-To: <rt-3.6.HEAD-14661-1187848451-962.23735-5-0 [...] rt.cpan.org>
References: <RT-Ticket-23735 [...] rt.cpan.org> <rt-3.6.HEAD-9082-1187498829-461.23735-6-0 [...] rt.cpan.org> <873ayassoo.fsf [...] k75.linux.bogus> <rt-3.6.HEAD-14661-1187848451-962.23735-5-0 [...] rt.cpan.org>
X-Virus-Checked: Checked
Content-Type: multipart/alternative; boundary="----=_Part_167024_28804876.1187876981059"
Received: from la.mx.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id 81B5E4D8044 for <bug-Module-Install [...] rt.cpan.org>; Thu, 23 Aug 2007 09:50:28 -0400 (EDT)
Received: (qmail 29418 invoked by alias); 23 Aug 2007 13:50:27 -0000
Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.178) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Thu, 23 Aug 2007 06:49:59 -0700
Received: by wa-out-1112.google.com with SMTP id m33so586912wag for <bug-Module-Install [...] rt.cpan.org>; Thu, 23 Aug 2007 06:49:54 -0700 (PDT)
Received: by 10.115.61.1 with SMTP id o1mr667596wak.1187876981106; Thu, 23 Aug 2007 06:49:41 -0700 (PDT)
Received: by 10.114.123.17 with HTTP; Thu, 23 Aug 2007 06:49:41 -0700 (PDT)
Delivered-To: cpan-bug+module-install [...] diesel.bestpractical.com
Subject: Re: [rt.cpan.org #23735] Patch against CPAN.pm batch jobs going into recursion
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tv5DjaVMNpWPFuPoYyklzRB9VU02bE+AP2q6eSlnPruusd8Qh9K/mqzlFsv1azb0GODIczAqzAEIAkgmXVyBpz6eWFHgmN08xArylfP2RGFunsXyfoJ4EhD+4riHYv/M+NpxtB7gmRGnaQ4kjSGNYhptpzt4N0+7cVldq3zvfQc=
Return-Path: <adamkennedybackup [...] gmail.com>
Dkim-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=B/8udR1/EZY55HpoO65wIr23yJGCW7gG1wFHknj/AxNQTl+ssmzVJg88olKVIv6JatZUrLIT+gA/D2zbsSd7SIuSDq2vOruiPGD1nEJXMwnWyz3ew7M9k2WclLtXLWPCZ4VaflwWaOZK+P6tRNvbW7Id7g1sbnNCKKM1RjiH6e8=
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: bug-Module-Install [...] rt.cpan.org
Date: Thu, 23 Aug 2007 23:49:41 +1000
Message-Id: <b8cb49a40708230649r2d4871e2nadfe745bf3318229 [...] mail.gmail.com>
To: bug-Module-Install [...] rt.cpan.org
From: "Adam Kennedy" <adamkennedybackup [...] gmail.com>
RT-Message-ID: <rt-3.6.HEAD-14667-1187877036-1694.23735-0-0 [...] rt.cpan.org>
Content-Length: 0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: ISO-8859-1
X-RT-Original-Encoding: utf-8
Content-Length: 2935
Download (untitled) / with headers
text/plain 2.8k
From my perspective, PERL5_CPANPLUS_IS_RUNNING was broken by design, primary because it doesn't do what it says. It just indicates that at some point above me, CPANPLUS was loaded into memory, not that it is running, and certainly not that CPANPLUS in particular happened to call the M:I Makefile.PL. As for the behaviour of M:I, what work I have done on it is to try and prevent it doing worse things. Certainly, setting PERL5_CPANPLUS_IS_RUNNING is now probably a good way to make M:I detect a "legacy" version of a CPAN client. After several long discussions in the irc.perl.org #toolchain channel, kane and I agreed on a new PERL5_CPANPLUS_IS_EXECUTING=/absolute/path/to/Makefile.PL, which provides the actual functionality that we need. As for why we need this stuff, it's to allow M:I to have some idea of what it is working with in terms of other members of the toolchain. Show quoted text
> I hope this desaster makes it > clear that none of us can solve this kind of problems alone.
I agree here. I know you hate using IRC, but if you could find a way to join the rest of the toolchain maintainers in irc.perl.org #toolchain, you'll find it's very low traffic, and a higher bandwidth forum might help to avoid this sort of problem in the future. If we are limited to stretched out disconnected conversations in mail and web forums, it's harder to co-ordinate. On 23/08/07, (Andreas J. Koenig) via RT <bug-Module-Install@rt.cpan.org> wrote: Show quoted text
> > > Queue: Module-Install > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=23735 > >
> >>>>> On Sun, 19 Aug 2007 00:47:14 -0400, "Michael G Schwern via RT" <
> bug-Module-Install@rt.cpan.org> said: >
> > Andres, I think Adam and Kane's comments happened during the RT email > > blackout. You should read them if you haven't.
> > Thanks Schwern! Indeed I did not receive these postings as mail. > > I'm sorry that I dispropriated PERL5_CPANPLUS_IS_RUNNING. This > decision wasn't done lightly. I waited for 6 months to get this > desastrous bug in Module::Install addressed and the only way to fix it > was setting this environment variable. Due to the nature of > Module::Install it is *never* upgraded, so this particular bug will > stay around forever. I changed my code now so that the variable is set > to $$. I fear I cannot stop using it for the time being. Maybe all > parties should agree on considering this variable being burnt by wrong > usage. Please deprecate it. > > I have not yet fully understood the advice from Adam. Can this find > its way into the Module::Install docs? Maybe with coding guidelines > how I'm consided to use this variable? I hope this desaster makes it > clear that none of us can solve this kind of problems alone. For me it > makes no sense why we need 4 environment variables to stop one > builder/installer from going wild but if you can paint the bigger > picture, I'll be glad to follow your lead. > > Thanks, > -- > andreas > >
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: ISO-8859-1
X-RT-Original-Encoding: ISO-8859-1
Content-Length: 3666
MIME-Version: 1.0
In-Reply-To: <rt-3.6.HEAD-24510-1173113129-45.23735-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
References: <rt-3.6.HEAD-24510-1173113129-45.23735-0-0 [...] rt.cpan.org>
Message-Id: <rt-3.6.HEAD-27796-1190061847-1908.23735-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
From: rt-cpan [...] trout.me.uk
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 1704
Download (untitled) / with headers
text/plain 1.6k
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.


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.