I have an option 3 that might be usable: Make it test for
$ENV{PERL_MM_USE_DEFAULT} in addition to $ENV{AUTOMATED_TESTING}.It may still be abuse, but it's less abusive, because that has to be explicitly configured, and it already implies that the installation should not be interactive, either. --Curtis On Tue, 25 Aug 2009 06:45 -0400, "David Golden" <[email protected]> wrote: > Zefram posted this to perl5-porters and I said I'd redirect it and > answer here. I'll top-post my reply to keep his email intact. Sorry > that it's inscrutable without reading his email. > > I prefer the alternatives in the order 0 1, 2. If Andreas is > convinced, perhaps he can ask Ilya. Or perhaps there's an alternative > to 1, which is Andreas and Ilya agreeing on a new method to skip tests > than abusing AUTOMATED_TESTING. With respect to 1, that's possible > now locally with distroprefs. I wouldn't do that in CPAN.pm for > T::R::P always but might special case it if it's part of Bundle::CPAN. > Before 2, I'd rather just fork T::R::P, call it > "Term::ReadLine::Perl::WithoutTests" or something and fix the test > script there. > > -- David > > ---------- Forwarded message ---------- > From: Zefram <[email protected]> > Date: Tue, Aug 25, 2009 at 4:40 AM > Subject: Term::ReadLine::Perl in Bundle::CPAN > To: [email protected] > > > Term::ReadLine::Perl is pissing me off. It has an obnoxious install > process, wherein "make test" starts up a program that uses the readline > facility and demands input from the tty. If you've got Term::ReadKey > installed, it even throws away typeahead. If you're installing it (as a > dependency of something else) on many perls consecutively, or from cron, > the installations grinds to a halt at that point. > > This obnoxious behaviour is a problem because T:RL:P is part of > Bundle::CPAN. It gets installed (or at least gets an attempt to install > it) pretty often. By proxy, Bundle::CPAN has obnoxious installation > behaviour. We need to fix this. I see three main possibilities for > doing this: > > (0) Get T:RL:P itself fixed. > > (1) Put a workaround into CPAN.pm. > > (2) Drop T:RL:P from Bundle::CPAN. > > I have so far tried approach 0, and it's not looking good. I submitted > a minimal patch, via RT, but the author refuses to believe that anyone > does "big installs" via automated tools such as CPAN.pm. Maybe someone > more diplomatic than I am can talk him round, but I suspect not. > > Approach 1 would be pretty easy, though of course Wrong. T:RL:P will > skip > the interactive test if it sees a true value in $ENV{AUTOMATED_TESTING}. > CPAN.pm could locally put that in the environment, specifically for > "make test" on T:RL:P. > > Approach 2 would preferably involve having some alternative full-editing > T:RL:* to include in the bundle. T:RL:Gnu is problematic because > it relies on a C library. There is a T:RL:Zoid, which on a cursory > look seems very satisfactory, and it even manages to test most of > the interactive behaviour without making the test suite interactive. > Using this automatically in CPAN.pm would require either CPAN.pm to > detect > it and set up $ENV{PERL_RL}, or a dual-lifed version of Term::ReadLine > that includes T:RL:Zoid among the defaults to look for. > > Preferences? > > -zefram -- Curtis Jewell [email protected] %DCL-E-MEM-BAD, bad memory -VMS-F-PDGERS, pudding between the ears [I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]
