Bug #48965 for Term-ReadLine-Perl: interactive test peeve

Mon Aug 24 09:47:40 2009 zefram [...] fysh.org - Ticket created

Subject:	interactive test peeve
Date:	Mon, 24 Aug 2009 14:47:09 +0100
To:	bug-Term-ReadLine-Perl [...] rt.cpan.org
From:	Zefram <zefram [...] fysh.org>

Term::ReadLine::Perl has an interactive test script, which requires entering a newline to make it proceed. This really gets in the way of bulk and automated installations. There's already an environment variable to disable the interactive test, but it's not a variable that's set by the CPAN shell or similar tools. The attached patch makes the test skip if it is running under the CPAN shell. -zefram

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

Mon Aug 24 12:26:37 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Mon, 24 Aug 2009 09:26:05 -0700
To:	Zefram via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Mon, Aug 24, 2009 at 09:47:41AM -0400, Zefram via RT wrote: Show quoted text

> Mon Aug 24 09:47:40 2009: Request 48965 was acted upon. > Transaction: Ticket created by zefram@fysh.org > Queue: Term-ReadLine-Perl > Subject: interactive test peeve > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: zefram@fysh.org > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=48965 > > > > Term::ReadLine::Perl has an interactive test script, which requires > entering a newline to make it proceed. This really gets in the way > of bulk and automated installations. There's already an environment > variable to disable the interactive test, but it's not a variable that's > set by the CPAN shell or similar tools. The attached patch makes the > test skip if it is running under the CPAN shell.

I see no reason to disable the test under CPAN shell. Hope this helps, Ilya

Mon Aug 24 12:26:37 2009 The RT System itself - Status changed from 'new' to 'open'

Mon Aug 24 12:31:02 2009 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Mon, 24 Aug 2009 17:30:41 +0100
To:	Ilya Zakharevich via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

Ilya Zakharevich via RT wrote: Show quoted text

>I see no reason to disable the test under CPAN shell.

The reason is that the test interferes with big installs. The CPAN command-line program doesn't necessarily have a human sitting in front of it. The test runs whenever Term::ReadLine::Perl is a dependency of something: the user didn't necessarily even know it was going to be installed. And whenever the test runs it brings progress to a grinding halt. -zefram

Mon Aug 24 17:32:13 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Mon, 24 Aug 2009 14:31:48 -0700
To:	Zefram via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Mon, Aug 24, 2009 at 12:31:03PM -0400, Zefram via RT wrote: Show quoted text

> Queue: Term-ReadLine-Perl > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=48965 > > > Ilya Zakharevich via RT wrote:

> >I see no reason to disable the test under CPAN shell.

> > The reason is that the test interferes with big installs.

It cannot be. CPAN.pm != "big installs" Show quoted text

> The CPAN command-line program doesn't necessarily have a human > sitting in front of it.

This is why the workaround is provided. Hope this helps, Ilya

Mon Aug 24 18:39:51 2009 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Mon, 24 Aug 2009 23:39:29 +0100
To:	Ilya Zakharevich via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

Ilya Zakharevich via RT wrote: Show quoted text

>It cannot be. CPAN.pm != "big installs"

Not true. I don't see where you'd get that idea. I routinely test my code against an array of 64 versions of perl that I have installed. I upgrade modules on all of these in batches, running the 64 versions of cpan(1) in sequence with the same arguments. Right now they're working through Bundle::CPAN, which is going to take a lot of time. I should be able to set that sort of thing going and leave it overnight. This works fine with most modules, but when Term::ReadLine::Perl gets involved it all stops. Show quoted text

>This is why the workaround is provided.

A workaround that is not standard and not invoked by any of the automated install tools. That doesn't cut it. libnet is the other module that's annoying me in this way at the moment. Its demand for input is less obnoxious than yours, because at least it doesn't throw away typeahead. It has a workaround too: put a certain file into its build directory before configuring. Also completely non-standard and not supported by CPAN.pm or anything similar. I sent GBARR a patch too. These workarounds are the wrong way round. They presume that human attention is the norm for Perl module installations, and that unattended installation is unusual. Further, they assume that the person wanting unattended installation is familiar with the details of the particular modules that demand input, in order to set up their individual flags. Any new module doing the same thing will still break the process. There is a protocol for how CPAN modules should build. The protocol is what makes CPAN.pm and its like work. Automated installation, by means of the protocol, is an essential capability. Anything that is incompatible with unattended installation should be invoked by other means. -zefram

Tue Aug 25 02:52:05 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Mon, 24 Aug 2009 23:51:41 -0700
To:	Zefram via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Mon, Aug 24, 2009 at 06:39:52PM -0400, Zefram via RT wrote: Show quoted text

> Queue: Term-ReadLine-Perl > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=48965 > > > Ilya Zakharevich via RT wrote:

> >It cannot be. CPAN.pm != "big installs"

> > Not true.

Plonk. Ilya

Tue Aug 25 09:33:21 2009 csjewell [...] cpan.org - Correspondence added

On Tue Aug 25 02:52:05 2009, nospam-abuse@ilyaz.org wrote: Show quoted text

> On Mon, Aug 24, 2009 at 06:39:52PM -0400, Zefram via RT wrote:

> > Queue: Term-ReadLine-Perl > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=48965 > > > > > Ilya Zakharevich via RT wrote:

> > >It cannot be. CPAN.pm != "big installs"

> > > > Not true.

> > Plonk. > > Ilya

I wouldn't plonk him quite so fast, although I would have said "That's not neccessarily true - you should see some of the multiple-machine installs I've had to do!" instead of what he DID say. The workaround is itself less correct than it could be, as it should be testing $ENV{PERL_MM_USE_DEFAULT} as well, which is what is usually set when people do not want interactive installations, but aren't neccessarily a CPAN smoker. Check for that, as well, and I would think 99% of complaints on this issue would disappear. And I'll add my voice to the tumult: Right now, we (meaning Adam Kennedy and I) have to special-case your module when building Strawberry Perl, because you don't check PERL_MM_USE_DEFAULT before doing an interactive portion of your installation. We shouldn't have to.

Tue Aug 25 15:00:29 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Tue, 25 Aug 2009 12:00:00 -0700
To:	Curtis Jewell via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Tue, Aug 25, 2009 at 09:33:22AM -0400, Curtis Jewell via RT wrote: Show quoted text

> > > >It cannot be. CPAN.pm != "big installs"

Show quoted text

> > > Not true.

Show quoted text

> > Plonk.

Show quoted text

> I wouldn't plonk him quite so fast, although I would have said "That's > not neccessarily true - you should see some of the multiple-machine > installs I've had to do!" instead of what he DID say.

I do "major runs" of CPAN.pm myself all the time (several hundreds of distributions). Show quoted text

> The workaround is itself less correct than it could be, as it should be > testing $ENV{PERL_MM_USE_DEFAULT} as well, which is what is usually set > when people do not want interactive installations, but aren't > neccessarily a CPAN smoker.

Could you explain this more? How would people know that they want to set this variable, and in which ways setting it is beneficial? Yours, Ilya

Wed Oct 28 04:32:05 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	Mailing list Perl5 <perl5-porters [...] perl.org>
Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Wed, 28 Oct 2009 01:31:45 -0700
To:	Curtis Jewell via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Tue, Aug 25, 2009 at 09:33:22AM -0400, Curtis Jewell via RT wrote: Show quoted text

> I wouldn't plonk him quite so fast, although I would have said "That's > not neccessarily true - you should see some of the multiple-machine > installs I've had to do!" instead of what he DID say. > > The workaround is itself less correct than it could be, as it should be > testing $ENV{PERL_MM_USE_DEFAULT} as well, which is what is usually set > when people do not want interactive installations, but aren't > neccessarily a CPAN smoker. Check for that, as well, and I would think > 99% of complaints on this issue would disappear.

I decided to invent a new name unilaterally. PERL_MM_NONINTERACTIVE If true, indicates that makemake'd modules should not be interactive. I recommend to test for it in addition to $ENV{PERL_MM_USE_DEFAULT} in makemaker itself, and document it for module writers. Likewise for Module::Builder? I think a) AUTOMATED_TESTING should be better confined to one particular situation - smoke tests. (There may be need to distinguish it from other types of non-interactive testing.) b) PERL_MM_USE_DEFAULT is already documented, and its design goal is too narrow; c) Due to chicken and egg, something should come first (usage in modules, usage in MakeMaker, documentation?). I did in Term::ReadLine::Perl 1.0303. Yours, Ilya

Wed Oct 28 06:11:33 2009 xdaveg [...] gmail.com - Correspondence added

CC:	Curtis Jewell via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Wed, 28 Oct 2009 06:10:54 -0400
To:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
From:	David Golden <xdaveg [...] gmail.com>

On Wed, Oct 28, 2009 at 4:31 AM, Ilya Zakharevich <nospam-abuse@ilyaz.org>wrote: Show quoted text

> I decided to invent a new name unilaterally. > > PERL_MM_NONINTERACTIVE > > If true, indicates that makemake'd modules should not be interactive. > >

I have a couple of issues with that. First, it's not clear what that should do. For prompt(), just use the default? Which is then just PERL_MM_USE_DEFAULT. And anything that isn't prompt has nothing to do with ExtUtils::MakeMaker or Module::Build. So this seems like just *your* particular desired %ENV variable name to avoid additional interaction. Show quoted text

> > a) AUTOMATED_TESTING should be better confined to one particular > situation - smoke tests. (There may be need to distinguish it > from other types of non-interactive testing.) > >

Have you read about the Oslo Consensus from the Perl QA Hackathon 2008? http://use.perl.org/~Alias/journal/36128 A dozen or so major toolchain/testing/QA people got together and agree on a definition for AUTOMATED_TESTING, specifically, to quote from Alias' journal: "We agreed that the current use of the $ENV{AUTOMATED_TESTING} flag to indicate an automated testing context where there is no recourse to a human operator." This says nothing about smoke testing. The operative term is "no recourse to a human operator". Automated, long-running builds of distributions like Strawberry are legitimate examples of situations where interruptions to prompt a human tester are not desired. The same could be true of a full install of a CPAN autobundle. AUTOMATED_TESTING would be a much better ENV variable to use, as its usage is increasingly standard under the consensus. Show quoted text

> b) PERL_MM_USE_DEFAULT is already documented, and its design goal is > too narrow; > >

Using PERL_MM_USE_DEFAULT as a special case for Term-Readline-Perl is a convenient hack. I would personally favor it, but can understand if you do not. Show quoted text

> c) Due to chicken and egg, something should come first (usage in > modules, usage in MakeMaker, documentation?). I did in > Term::ReadLine::Perl 1.0303. >

I would strongly encourage you to change it to AUTOMATED_TESTING, per my explanation above. I don't see any value in adding PERL_MM_NONINTERACTIVE support to ExtUtils::MakeMaker or Module::Build. (In fact, arguably they should be honoring AUTOMATED_TESTING and treating that as PERL_MM_USE_DEFAULT anyway). Support for setting AUTOMATED_TESTING could be added to CPAN.pm and CPANPLUS. (E.g. "cpan> noprompt test Foo::Bar") -- David

Wed Oct 28 07:31:43 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #48965] interactive test peeve
Date:	Wed, 28 Oct 2009 04:30:10 -0700
To:	David Golden via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Wed, Oct 28, 2009 at 06:11:34AM -0400, David Golden via RT wrote: Show quoted text

> > I decided to invent a new name unilaterally. > > > > PERL_MM_NONINTERACTIVE > > > > If true, indicates that makemake'd modules should not be interactive.

Show quoted text

> I have a couple of issues with that. First, it's not clear what that should > do.

This is chicken and egg. It has two ends: a) users should set it when they run a build non-interactively; b) module build procedures should check it (in addition to AUTOMATED_TESTING) before asking user anything. Show quoted text

> For prompt(), just use the default? Which is then just > PERL_MM_USE_DEFAULT.

Yes, inside MM, it is equivalent to PERL_MM_USE_DEFAULT. Show quoted text

> And anything that isn't prompt has nothing to do with > ExtUtils::MakeMaker or Module::Build.

I do not think you grasp it: the problem is WHERE to document this variable. Currently, the only place is in documenation of ExtUtils::MakeMaker and Module::Build. Other than documenting this variable, ExtUtils::MakeMaker should behave "just as agent of build procedures", and do not ask the user anything if PERL_MM_NONINTERACTIVE is set. Again: PERL_MM_NONINTERACTIVE: for usage both by Makefile.PL and MM; PERL_MM_USE_DEFAULT: for usage by MM Show quoted text

> A dozen or so major toolchain/testing/QA people got together and agree on a > definition for AUTOMATED_TESTING, specifically, to quote from Alias' > journal: > > "We agreed that the current use of the $ENV{AUTOMATED_TESTING} flag to > indicate an automated testing context where there is no recourse to a human > operator."

Given this, a different variable name defined SPECIFICALLY for smoke testing may be a better solution indeed. Show quoted text

> I would strongly encourage you to change it to AUTOMATED_TESTING, per my > explanation above.

I cannot. AUTOMATED_TESTING is supported for several years already. ;-) Show quoted text

> Support for setting AUTOMATED_TESTING could be added to CPAN.pm and > CPANPLUS. (E.g. "cpan> noprompt test Foo::Bar")

This is a very good idea. Yours, Ilya

Tue Dec 20 11:43:26 2011 rt-cpan [...] trout.me.uk - Correspondence added

On Wed Oct 28 07:31:43 2009, nospam-abuse@ilyaz.org wrote: Show quoted text

> On Wed, Oct 28, 2009 at 06:11:34AM -0400, David Golden via RT wrote:

> > > I decided to invent a new name unilaterally. > > > > > > PERL_MM_NONINTERACTIVE > > > > > > If true, indicates that makemake'd modules should not be

> interactive. >

> > I have a couple of issues with that. First, it's not clear what

> that should

> > do.

> > This is chicken and egg. It has two ends: > > a) users should set it when they run a build non-interactively; > > b) module build procedures should check it (in addition to > AUTOMATED_TESTING) > before asking user anything.

Two years on, the convention seems to have stablised as: PERL_MM_USE_DEFAULT=1 means "don't do anything that requires me to provide input" and the user should expect the test and install process to complete using all defaults and without any requirement for interactivity (or to fail if the default settings aren't suitable) AUTOMATED_TESTING=1 means "I am a smoke tester" and will often activate significant extra testing in modules that care about cross platform/perl reporting. While I can see that a PERL_MM_NONINTERACTIVE is a nice theoretical concept, there's been no real take up that I've seen for such a thing, and PERL_MM_USE_DEFAULT has de facto become the thing that's used for that purpose. I'd propose that your logic becomes: my $non_int = (defined($ENV{PERL_MM_NONINTERACTIVE})) ? $ENV{PERL_MM_NONINTERACTIVE} : $ENV{PERL_MM_USE_DEFAULT}) || $ENV{AUTOMATED_TESTING}; since this will obey the principle of least surprise for users while additionally upgrading gracefully should PERL_MM_NONINTERACTIVE ever get toolchain/user attention.

Tue Jan 15 07:53:06 2013 perl [...] toby.ink - Correspondence added

This bug annoyed me this morning. I've recently upgraded my OS, so have been setting up a new Perl installation. This morning I set in motion an install of about 40 distributions, and when I came back a couple of hours later, expecting to find it all installed, it had paused after just four installations waiting for me to hit enter a couple of times for Term-ReadLine-Perl's test suite.