in reply to Re: Trojan Perl Distributions
in thread 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.

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.

Replies are listed 'Best First'.
Re: Re: Re: Trojan Perl Distributions
by demerphq (Chancellor) on May 06, 2004 at 19:55 UTC

    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]

        Last I looked into it it didnt. Ill have to look again.


        ---
        demerphq

          First they ignore you, then they laugh at you, then they fight you, then you win.
          -- Gandhi
[reply]
[d/l]
      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]

        Well, installing the DDS alias is a form of namespace pollution that a normal user/enviornment may not want. It may even conflict. So in a 'follow' session I don't want to install DDS unless they already have DDS installed. Its possible that doing so without them noticing may even overwrite a different DDS that they have installed. OTOH, on a CPAN-Tester enviornment I believe that such an overwite would be immaterial. Its a test enviornment and such things can and will happen and as such shouldnt be of a signifigant impact, so I would want the tester to test the DDS extension too. If it got overwitten by another module afterwards, or overwrote an existing DDS it probably wouldnt matter. But in a non-tester scenario id wouldnt want to run the risk.


        ---
        demerphq

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

In Section Meditations