FAQ
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 <zefram@fysh.org>
Date: Tue, Aug 25, 2009 at 4:40 AM
Subject: Term::ReadLine::Perl in Bundle::CPAN
To: perl5-porters@perl.org


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

Search Discussions

  • Curtis Jewell at Aug 25, 2009 at 3:23 pm
    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" 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 <zefram@fysh.org>
    Date: Tue, Aug 25, 2009 at 4:40 AM
    Subject: Term::ReadLine::Perl in Bundle::CPAN
    To: perl5-porters@perl.org


    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
    swordsman@csjewell.fastmail.us

    %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]
  • Zefram at Aug 25, 2009 at 3:38 pm

    Curtis Jewell wrote:
    I have an option 3 that might be usable: Make it test for
    $ENV{PERL_MM_USE_DEFAULT} in addition to $ENV{AUTOMATED_TESTING}.
    CPAN.pm doesn't currently set that variable. Are you proposing that it
    should? Always or dependent on a configuration option? Just for T:RL:P?
    This sounds like a variant on my option 1, workaround in the toolchain.

    -zefram
  • David Golden at Aug 25, 2009 at 4:52 pm

    On Tue, Aug 25, 2009 at 11:37 AM, Zeframwrote:
    Curtis Jewell wrote:
    I have an option 3 that might be usable: Make it test for
    $ENV{PERL_MM_USE_DEFAULT} in addition to $ENV{AUTOMATED_TESTING}.
    CPAN.pm doesn't currently set that variable.  Are you proposing that it
    should?  Always or dependent on a configuration option?  Just for T:RL:P?
    This sounds like a variant on my option 1, workaround in the toolchain.
    I had the same thought Curtis had'. PERL_MM_USE_DEFAULT is a
    "standard" signal that a user doesn't want to be prompted. It would
    let Ilya keep tests by default, but allow users to opt-out.

    No, CPAN.pm doesn't currently set it, but it's been on my list of
    "nice to have" features to add, along with the equivalent for
    auto-install.

    I could imagine (yet another) CPAN config option to use defaults for
    prompts or possibly a pragma for the shell, working like this:

    cpan> noprompt install Bundle::CPAN

    And regardless, there's always;

    $ PERL_MM_USE_DEFAULT=1 perl -MCPAN -e shell

    Other ideas? If not, could someone please go open a ticket with this
    wishlist item on the Term::ReadLine::Perl RT (ideally with a patch)
    and we can weigh in with our support.

    -- David
  • Andreas J. Koenig at Aug 25, 2009 at 9:44 pm

    On Tue, 25 Aug 2009 12:51:39 -0400, David Golden said:
    And regardless, there's always;
    $ PERL_MM_USE_DEFAULT=1 perl -MCPAN -e shell
    Other ideas?
    I think I'd favor a solution that allows bundles to inject distroprefs
    for the bundled modules. Users of distroprefs are not pissed off by
    T:R:P because they simply have installed the following file in their
    distroprefs folder:

    ---
    match:
    distribution: '^ILYAZ/modules/Term-ReadLine-Perl-\d'
    test:
    expect: ["Enter arithmetic or Perl expression", "\n"]


    So what we really want is pushing such a config into a bundle so that
    it can do the miracles it is supposed to do.

    Something like this, haven't understood all the details involved in
    this idea (BTW, I got it from Ilya;)


    --
    andreas
  • David Golden at Aug 25, 2009 at 10:25 pm

    On Tue, Aug 25, 2009 at 5:42 PM, Andreas J. Koenigwrote:
    I think I'd favor a solution that allows bundles to inject distroprefs
    for the bundled modules. Users of distroprefs are not pissed off by
    T:R:P because they simply have installed the following file in their
    distroprefs folder:

    ---
    match:
    distribution: '^ILYAZ/modules/Term-ReadLine-Perl-\d'
    test:
    expect: ["Enter arithmetic or Perl expression", "\n"]


    So what we really want is pushing such a config into a bundle so that
    it can do the miracles it is supposed to do.

    Something like this, haven't understood all the details involved in
    this idea (BTW, I got it from Ilya;)
    The downside or limitation is that I think it only works where expect
    does. I recall there were issues on Windows, but I don't know if
    those ever got fixed.

    David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedAug 25, '09 at 10:46a
activeAug 25, '09 at 10:25p
posts6
users4
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase