Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: Re: Re: Trojan Perl Distributions

by demerphq (Chancellor)
on May 06, 2004 at 19:55 UTC ( [id://351264]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Trojan Perl Distributions
in thread Trojan Perl Distributions

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


Replies are listed 'Best First'.
Re: Re: Re: Re: Trojan Perl Distributions
by autarch (Hermit) on May 06, 2004 at 21:08 UTC

    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?

      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


Re^4: Trojan Perl Distributions
by adrianh (Chancellor) on May 07, 2004 at 13:41 UTC
    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?

      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


        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.

        It seems to me that you have two separate issues:

        1. Whether to test the DDS alias
        2. Whether to install the DDS alias

        If it were me I would always do (1) and only do (2) if the user asked for it, defaulting to "no" in non-interactive environments.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://351264]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (8)
As of 2024-03-28 11:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found