in reply to Trojan Perl Distributions

I think one issue here is that test authors need a way to know they are running on a cpan-tester box. I think if there were a clear way to signal various things, (like no interactive prompts, on a cpan-tester's box, no live db tests, etc) then module writers would take advantage of it.

For instance i have an option to install 'DDS' as an alias to Data::Dump::Streamer, on a cpan-tester's box I would like it to be installed automatically, on an interactive install id like it to ask if it should be installed, and on an automatic install id like it only to be installed if it already is. But unfortunately I can't work out how to know these things, so I had to use a clumsy means to more or less (less :-) get the right behaviour. As a tester, maybe you know of a flag or env var or something that would tell us we are on a cpan-tester enviornment and should behave accordingly?


---
demerphq

    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi

Replies are listed 'Best First'.
Re: Re: Trojan Perl Distributions
by barbie (Deacon) on May 06, 2004 at 11:48 UTC
    This isn't guaranteed, but may be useful. As part of smoke testing an environment variable is set to know whether automated testing or manual testing is being performed. This is then used to determine whether a text editor needs to be invoked to allow the tester to make additional comments.

    something like... 

    my $autotesting = 1 if($ENV{VISUAL} eq 'echo');

    [download]
    ... might work. Unfortunately I cannot test this myself, as I'm about to head off to a London.pm social meeting :)

    --
    Barbie | Birmingham Perl Mongers | http://birmingham.pm.org/

[reply]
[d/l]
Re^2: Trojan Perl Distributions
by adrianh (Chancellor) on May 06, 2004 at 16:23 UTC
    I think one issue here is that test authors need a way to know they are running on a cpan-tester box. I think if there were a clear way to signal various things, (like no interactive prompts, on a cpan-tester's box, no live db tests, etc) then module writers would take advantage of it.

    There are already some mechanisms to help support this in Module::Build (notes, prompt, y_n) and ExtUtils::MakeMaker (PERL_MM_USE_DEFAULT, prompt). Both of them have systems that allow you to prompt the user, or switch to a default if running in a non-interactive mode.

    If a module is using either of these systems and the Makefile/Build.PL is run with STDIN attached to something that doesn't look like a terminal then the user shouldn't be prompted for input.

    As a tester, maybe you know of a flag or env var or something that would tell us we are on a cpan-tester enviornment and should behave accordingly?

    I think that's the wrong distinction to be looking at. The whole point of cpan-testers is that it gives feedback on how well modules build. If you do something different on cpan-testers from what you do on a normal build some of the utility disappears.

    Instead we need to look at whether the build is happening in an interactive manner or not, and have appropriate default actions when the session isn't interactive.

[reply]
[d/l]
[select]

      There are already some mechanisms to help support this in Module::Build (notes, prompt, y_n) and ExtUtils::MakeMaker (PERL_MM_USE_DEFAULT, prompt).

      Well, since im dealing with XS Module::Build doesnt help me much afaict. As For MakeMaker, well, lets just say that how to exploit these features isn't well documented. I still don't know how to do what I want. If you have knowledge about these matters Id love to see a meditation or tutorial on them :-)

      update: ok now that I know what to search for I found what you mean. Thats definately a step forward. If there was an $ENV{CPAN_TESTER} flag to go with the $ENV{PERL_MM_USE_DEFAULT} I'd have pretty much everything that I want.

      I think that's the wrong distinction to be looking at. The whole point of cpan-testers is that it gives feedback on how well modules build. If you do something different on cpan-testers from what you do on a normal build some of the utility disappears.

      Well, Im not with you here im sorry to say. What im concerned with is enabling optional features to be tested by CPAN testers. Since certain features are optional under a tester scenario I want the default to be different from what it would be in a 'follow' CPAN session. In the 'follow' scenario I want it to install/test the DDS alias only if its installed already. On a cpan tester enviornment i want the DDS alias tested, in an interactive enviornment I want the user to decide (if they havent already installed it). So knowing which scenario I was in would be very useful.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi
[reply]
[d/l]

        Well, since im dealing with XS Module::Build doesnt help me much afaict.

        Module::Build works with XS. So how doesn't it help you?

[reply]
        What im concerned with is enabling optional features to be tested by CPAN testers. Since certain features are optional under a tester scenario I want the default to be different from what it would be in a 'follow' CPAN session. In the 'follow' scenario I want it to install/test the DDS alias only if its installed already. On a cpan tester enviornment i want the DDS alias tested

        Sorry - I'm not understanding this. Why would you want to do different things for non-interactive vs. cpan tester?

[reply]

In Section Meditations