> Ayhan Ulusoy wrote: > > If I may add my grain of salt as an -interested- user for this one... > > > > Here's how I would expect PERL5LIB to work : > > Sorry for cutting you short, Ayhan, but we can't and shouldn't change the > way > PERL5LIB works under mp.
[Ayhan] I am afraid you _have_ cut it short, Stas. Perhaps even before reading it :) Admittedly, I have generated quite a bit of traffic this week-end, and you seem like a busy man. So, I'll let it slip this time :-) But please do me a favour and read it. -- it's attached. > We agreed that it was a mistake under mp1. We > simply > comply with perl and do nothing special about it. If you have further > thoughts > on PERL5LIB, please make yourself heard on the p5p list. [Ayhan] But I am perfectly happy with the way Perl handles PERL5LIB, and agree that mod_perl should keep the Perl way. But it doesn't ... so that's why I'm bringing it up in the mod-perl dev list, not p5p. If you are referring to the behaviour with regards to '-T', I don't have any problems with the way Perl handles it. Yes, mp1 behaviour for PERL5LIB under '-T' was a mistake. The mp2 way is GOOD with regards to that. I had not said anything to the contrary. What is described in my original post is basically what Geoff was talking about. In a nutshell, it's about being a able to set PERL5LIB on a per Server/Directory/Location or per request basis. This works perfectly well today with perl scripts running under MOD_CGI. Under MOD_CGI, I can do a "SetEnv PERL5LIB =xyz" on a per Directory/Location or even Request basis (via mod_rewrite). Since the perl interpreter will be invoked each and every time for a CGI script, it will take that PERL5LIB into account. If I am not mistaken, "ModPerl::PerlRun" and to some extent "ModPerl::Registry" are designed to emulate MOD_CGI behaviour. The way things are today, they DON'T --as far as PERL5LIB is concerned. On the other hand, performance may certainly be an issue here. That's why I have suggested that this behaviour be optional. Geoff, don't you have any comments here ? Please heeeeelp :) > > If you want to change @INC in mp2, you should use the lib pragma in the > startup file or the PerlSwitches -I idiom. Do always use -T and don't use > PERL5LIB (because it's ignored with -T). [Ayhan] Again, I have no problems whatsoever with the way Perl behaves with respect to PERL5LIB under '-T'. It _should_ behave that way. Please read the attached post. It attempts to answer your question as to why Perl does it that way, and why that is good. Agreed also that it is good to use '-T' as a rule of thumb, especially in production environments. On the other hand, Perl gives me the choice whether or not I want to use '-T' in a given situation. It's good to have that choice. Cheers, Ayhan
--- Begin Message --- Title: RE : [PATCH] add PERL5LIB to @INC in the correct order
Taint mode is another business.
It is the "paranoid" mode, where anything that comes from the outside
world, including the environment, is considered untrusted by default,
until you explicitly untaint it.If I,
*) know (or guess) that your code calls SomeModule->doSomething(),
*) have a way to set up PERL5LIB
*) gained write access to some directory (say /tmp)I could cause your script to do anything I want when it calls
SomeModule->doSomething().
One may say, those "if"s are unlikely to occur, but this is the
"paranoid" mode, where "unlikely" is not in the dictionary.The strict behaviour of taint-mode forces the script to do a "use lib"
explicitly if it wants to "use" modules from some non-standard
directory.Cheers,
Ayhan
-----Message d'origine-----
De�: Geoffrey Young [mailto:[EMAIL PROTECTED]]
Envoy�: vendredi 17 octobre 2003 01:56
��: Stas Bekman
Cc�: [EMAIL PROTECTED]
Objet�: Re: [PATCH] add PERL5LIB to @INC in the correct order
> OK, I'm convinced on this one. We should add a new entry to
> porting/compat.pod then, including you summary above. Should I do
that,
> or will you handle that.I'll put it on my ToDo.
>
> I still want to know why PERL5LIB is ignored by perl, I will ask p5p
as
> perlsec.pod doesn't say anything about it.yeah, me too.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
--- Begin Message --- Title: RE : [PATCH] add PERL5LIB to @INC in the correct order
If I may add my grain of salt as an -interested- user for this one...
Here's how I would expect PERL5LIB to work :
1) Ability to set it in httpd.conf on a per server, vhost,
directory or location basis.
2) Ability to set it on a per request basis as well (via SetEnvIf or
mod_rewrite)
Where would this be useful? Especially in DEVELOPMENT/TEST
environments.Somebody might be working on (read : breaking into pieces) some module
which is "used" by several mod_perl/CGI scripts. The stuff needs to be
tested before it can even become part of the "development environment"
where others work on different parts of the project and count on modules
"working correctly".If the above were supported, I could set up an alternate location/
ScriptAlias for the CGI scripts where the PERL5LIB points to a set of
modules to be tested , and do the dirtiest of things without impacting
my co-workers.The reason I prefer PERL5LIB over PerlSwitches, besides it being more
familiar, is that it is more flexible : there are 50 million ways to set
up an environment variable.Right now, the only way we have is to set up a different vhost to get
this kind of thing working.If I am guessing correctly, if mod_perl was to support this kind of
behaviour, it would mean mingling with @INC on every request, or at
least checking if it would need to be mingled. This may not be very
cheap in terms of overhead.Besides, it might be quite a headache to implement because of how the
"use/require" mechanism works. That is, the %INC hash would need to be
invalidated whenever @INC would change. This is all expensive stuff.
So, my suggestion is to have a switch (on a vhost or interpreter pool
basis) that would control the way PERL5LIB is handled. Much like the
"reload" switch. It could be "normally off" so that it doesn't cause
much of an overhead on the production. It could also require that
setup-environment be "on" for it to work.
As a last word : if it can't work as it should, I think it's better to
turn the behaviour off until it can, so that people don't rely on it
behaving incorrectly.
Cheers,
Ayhan
-----Message d'origine-----
De�: Geoffrey Young [mailto:[EMAIL PROTECTED]]
Envoy�: vendredi 17 octobre 2003 01:56
��: Stas Bekman
Cc�: [EMAIL PROTECTED]
Objet�: Re: [PATCH] add PERL5LIB to @INC in the correct order
> OK, I'm convinced on this one. We should add a new entry to
> porting/compat.pod then, including you summary above. Should I do
that,
> or will you handle that.I'll put it on my ToDo.
>
> I still want to know why PERL5LIB is ignored by perl, I will ask p5p
as
> perlsec.pod doesn't say anything about it.yeah, me too.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
