You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Simon Flack <sf...@flacks.net> on 2003/09/29 19:58:04 UTC
[PATCH] add PERL5LIB to @INC in the correct order
Problem:
at the beggining of each request PERL5LIB is prepended to @INC in
reverse order. E.g.:
SetEnv PERL5LIB "one:two:three:four"
results in this:
@INC = ('four', 'three', 'two', 'one', '/usr....', '...');
Environment:
Tested with perl 5.6.1, mod_perl 1.27 and 1.28
A patch is attached to src/modules/perl/perl_util.c that adds the PERL5LIB
variables in the correct order.
Also attached is a test script and .htaccess that demonstrate the bug.
Notes:
There might be a more elegent way of doing it.
Apologies if the patch doesn't conform to the style guide - couldn't
find it, and couldn't work out what indenting to use from looking.
--simonflk
Namespace for 3rd party general-purpose mp2 modules
Posted by Ayhan Ulusoy <ay...@drexel.edu>.
Do we have an "official" namespace for general-purpose third-party
modules meant to be run under "mp2" ?
In mp1, "Apache" was widely used for this purpose, but it's no good...
The docs speak about "MyApache", but it just doesn't sound right.
Another thing : would it not be better to separate plain-old response
handlers from, say, filters.
Now that 1.99_10 is out, and that the filter API hasn't changed for a
whole 6 months :), I'd like to release on CPAN a general-purpose
output-filter as a replacement for "Sandwich", but which can also work
with wrapper templates (it's called CheeseBurger right-now).
The code has been there for a while and works. I just need to add
support for the Sandwich options, so that it would be a drop-in
replacement.
Under which namespace do I release it?
Cheers,
Ayhan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Ayhan Ulusoy <ay...@drexel.edu>.
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:geoff@modperlcookbook.org]
Envoyé : vendredi 17 octobre 2003 01:56
À : Stas Bekman
Cc : dev@perl.apache.org
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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Ayhan Ulusoy wrote:
>>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 :)
I'm sure he did read it. he even updated the docs accordingly.
> Geoff, don't you have any comments here ? Please heeeeelp :)
yes. I agree with stas - PERL5LIB should be left to perl, and left without
interference from mod_perl.
keep in mind that PERL5LIB _does_ indeed work: provided your interpreter is
not running under -T and $ENV{PERL5LIB} is populated when the interpreter is
spawned, it will be recognized.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> So I am a lazy dude who likes to blindly switch between mod_cgi and
>> mod_perl with less then 10 key-strokes. And that's why I have been
>> typing several thousand key-strokes for this thread ;)
>
>
> Got your idea. And as mentioned above mod_perl works exactly the same as
> mod_cgi, with regards to PERl5LIB under indentical perl flags.
well, that's not completely true. in mod_cgi you can toggle -T on a
per-script basis, so some scripts would be able to use PERL5LIB while others
would not. with mod_perl PERL5LIB is all or nothing, depending on the
global -T setting. but if you think about it from an interpreter point of
view, then yes, things are the same - if the interpreter is started without
taint checking and PERL5LIB is populated, it will affect @INC.
Registry and mod_cgi will never be _exactly_ the same - they are close, but
to get the increased speed some things end up being different.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
>>> But please do me a favour and read it. -- it's attached.
>>
>>
>> I did now, and you bring points that Geoff has already mentioned:
>> PERL5LIB setting per-dir doesn't work in mp1, so it won't work under mp2.
>
>
> Don't understand the 'so' connector here. Are you suggesting that there
> may be "httpd.conf" files out there today which do set PERL5LIB (of all
> things) in a directory section without the actual intention of that
> having any effect, so that they would suddenly break upon upgrading to
> mp2 ??? --especially if the behavior is governed by a switch (like
> SetupPERL5LIB ) as suggested earlier, I would rather think that is
> unlikely.
No, what I meant that per-dir setting of PERL5LIB never worked in mp1, so it
won't be broken in mp2.
>> The solution is simple - don't use PERL5LIB, use PerlSwitches as I've
>> documented here:
>> http://perl.apache.org/docs/2.0/user/config/config.html#Adjusting_C__INC_
>> http://perl.apache.org/docs/2.0/user/config/config.html#Modifying_C__INC__on_a_Per_VirtualHost
>>
>>
>> So the Vhost solution perfectly answers your problem with setting up a
>> different @INC, for different setups running on the same server.
>
>
>
> That's what I have been doing, and willing to do as a work-around until
> I convince you to put in the feature ;) or until I end up hacking
> something on my own.
> Cause what I need is really per-dir. There's no hurry though....
btw, on p5p someone has mentioned a module called perl5lib available from
CPAN, which bypasses perl's security guards. I've added that info to the above
URL.
>> Another crafty solution would be to use PerlInitHandler to push some
>> libs onto @INC and PerlCleanupHandler to pop them away.
>> Apache::PerlVINC in mp1 does exactly that. Feel free to port it to mp2
>> / talk to the author first?
>> http://search.cpan.org/~davem/Apache-PerlVINC-0.03/PerlVINC.pm
>
>
>
> It might perhaps be an option, but only if I can manage to extend it so
> that it can optionally use PERL5LIB instead of a fixed set of
> directories. But for that, the environment needs to have been set up
> already, I am not sure it is at the PerlInitHandler phase. Need to check
> it out;
PerlPassEnv PERL5LIB will do the trick. And sure you can adjust that module to
optionally work with that env var.
> In any case, I am thinking more and more that this "feature" may belong
> to ModPerl::RegistryCooker at the end of the day and not to mod_perl
> itself, since the divergence is with regard to mod_cgi.
> For a CGI, one expects PERL5LIB to work the same way as under mod_cgi.
> A "pure" perl handler, on the other hand, knows that it lives in a
> persistent interpreter which naturally processes its PERL5LIB at
> start-up time.
Eh? a perl program running under mod_cgi and -T won't respect PERL5LIB. Do you
say that your programs run without -T? In that case, don't run mod_perl with
-T and voila you get PERL5LIB.
> Given that, how about if I submitted a patch to RegisteryCooker, which
> already mingles with INC in its "run" method. Subclassing could also be
> an option for some time (until you are convinced), overriding the "run"
> method.
Sure, you can always do that.
> Below is my poor man's use-case that has motivated me for all this :
>
> I love it when an application works both under mod_cgi and mod_perl.
> Call me a maniac (but I am not alone). I allow myself (and the rest of
> the poor team here) to use mod_perl & apache specific features _only_
> for non-response handlers (filters & such) Except on extremely rare
> occasions, anything that generates a response is written to be a plain
> CGI script without any global variables (so that they will work under
> mod-perl). The CGI script will handle anything that is "web-related"
> (relying on CGI.pm and TT). All "business logic", as they call it, is
> done in specialized modules who know nothing about the web or HTML or
> anything.
>
> Yes, this may be keeping us from unleashing the full power of mp, but it
> also keeps us from other headaches, especially while mp is going thru
> change.
Response handlers aren't going through a change. Expect them to stay as they
are now.
> Throughout the development phase, we test under both mod_cgi and
> mod_perl, switching between them frequently (actually this is also quite
> useful for testing parts of mp2, as it lets you see where it diverges.
> Another advantage is to actually experience --and appreciate over and
> over again-- the performance gains that mod_perl brings. Add to that
> some CGI::Cache, and some "memoize" & singleton magic which really comes
> to life only under mod-perl, you're set for a pleasant ride...)
>
> Under mod_cgi, we have to use PERL5LIB; for mod_perl PerlVINC
> force(s/d) you to use some other "api". Ain't good.
>
> So I am a lazy dude who likes to blindly switch between mod_cgi and
> mod_perl with less then 10 key-strokes. And that's why I have been
> typing several thousand key-strokes for this thread ;)
Got your idea. And as mentioned above mod_perl works exactly the same as
mod_cgi, with regards to PERl5LIB under indentical perl flags.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Ayhan Ulusoy <ay...@qovo.net>.
>
>Guilty as charged, but I said that in first place ;)
... snip ...
> Therefore please bear with me and feel free to nudge me if my
> in-head-filter has ignored your email, just like you did now ;)
Don't worry Stas, and thanks for bearing with me bombarding you with lots
of babble.
Besides, this is not an urgent topic for me, so please feel free to let it
sleep for a while...
>>But please do me a favour and read it. -- it's attached.
>
>I did now, and you bring points that Geoff has already mentioned: PERL5LIB
>setting per-dir doesn't work in mp1, so it won't work under mp2.
Don't understand the 'so' connector here. Are you suggesting that there may
be "httpd.conf" files out there today which do set PERL5LIB (of all
things) in a directory section without the actual intention of that having
any effect, so that they would suddenly break upon upgrading to mp2
??? --especially if the behavior is governed by a switch (like
SetupPERL5LIB ) as suggested earlier, I would rather think that is unlikely.
>The solution is simple - don't use PERL5LIB, use PerlSwitches as I've
>documented here:
>http://perl.apache.org/docs/2.0/user/config/config.html#Adjusting_C__INC_
>http://perl.apache.org/docs/2.0/user/config/config.html#Modifying_C__INC__on_a_Per_VirtualHost
>
>So the Vhost solution perfectly answers your problem with setting up a
>different @INC, for different setups running on the same server.
That's what I have been doing, and willing to do as a work-around until I
convince you to put in the feature ;) or until I end up hacking something
on my own.
Cause what I need is really per-dir. There's no hurry though....
>Another crafty solution would be to use PerlInitHandler to push some libs
>onto @INC and PerlCleanupHandler to pop them away. Apache::PerlVINC in mp1
>does exactly that. Feel free to port it to mp2 / talk to the author first?
>http://search.cpan.org/~davem/Apache-PerlVINC-0.03/PerlVINC.pm
It might perhaps be an option, but only if I can manage to extend it so
that it can optionally use PERL5LIB instead of a fixed set of directories.
But for that, the environment needs to have been set up already, I am not
sure it is at the PerlInitHandler phase. Need to check it out;
In any case, I am thinking more and more that this "feature" may belong to
ModPerl::RegistryCooker at the end of the day and not to mod_perl
itself, since the divergence is with regard to mod_cgi.
For a CGI, one expects PERL5LIB to work the same way as under mod_cgi. A
"pure" perl handler, on the other hand, knows that it lives in a persistent
interpreter which naturally processes its PERL5LIB at start-up time.
Given that, how about if I submitted a patch to RegisteryCooker, which
already mingles with INC in its "run" method. Subclassing could also be an
option for some time (until you are convinced), overriding the "run" method.
Below is my poor man's use-case that has motivated me for all this :
I love it when an application works both under mod_cgi and mod_perl. Call
me a maniac (but I am not alone). I allow myself (and the rest of the poor
team here) to use mod_perl & apache specific features _only_ for
non-response handlers (filters & such) Except on extremely rare
occasions, anything that generates a response is written to be a plain CGI
script without any global variables (so that they will work under
mod-perl). The CGI script will handle anything that is "web-related"
(relying on CGI.pm and TT). All "business logic", as they call it, is done
in specialized modules who know nothing about the web or HTML or anything.
Yes, this may be keeping us from unleashing the full power of mp, but it
also keeps us from other headaches, especially while mp is going thru change.
Throughout the development phase, we test under both mod_cgi and mod_perl,
switching between them frequently (actually this is also quite useful for
testing parts of mp2, as it lets you see where it diverges. Another
advantage is to actually experience --and appreciate over and over again--
the performance gains that mod_perl brings. Add to that some CGI::Cache,
and some "memoize" & singleton magic which really comes to life only under
mod-perl, you're set for a pleasant ride...)
Under mod_cgi, we have to use PERL5LIB; for mod_perl PerlVINC
force(s/d) you to use some other "api". Ain't good.
So I am a lazy dude who likes to blindly switch between mod_cgi and
mod_perl with less then 10 key-strokes. And that's why I have been typing
several thousand key-strokes for this thread ;)
Cheers,
Ayhan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Ayhan Ulusoy wrote:
> 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 :-)
Guilty as charged, but I said that in first place ;) Since I've to read email
traffic on about 15 or so mailing lists, all in one way or another affecting
mod_perl, I have to adopt some sort of filtering in my head, without which I
won't be able to do any work at all, but spend all the time just reading
emails all day long. So normally I do that by looking at the subject and
sometimes the first para of the post. [that's another reason why I asked you
to post different issues in different posts ;)]. Therefore please bear with me
and feel free to nudge me if my in-head-filter has ignored your email, just
like you did now ;)
> But please do me a favour and read it. -- it's attached.
I did now, and you bring points that Geoff has already mentioned: PERL5LIB
setting per-dir doesn't work in mp1, so it won't work under mp2.
> 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.
The solution is simple - don't use PERL5LIB, use PerlSwitches as I've
documented here:
http://perl.apache.org/docs/2.0/user/config/config.html#Adjusting_C__INC_
http://perl.apache.org/docs/2.0/user/config/config.html#Modifying_C__INC__on_a_Per_VirtualHost
So the Vhost solution perfectly answers your problem with setting up a
different @INC, for different setups running on the same server.
Another crafty solution would be to use PerlInitHandler to push some libs onto
@INC and PerlCleanupHandler to pop them away. Apache::PerlVINC in mp1 does
exactly that. Feel free to port it to mp2 / talk to the author first?
http://search.cpan.org/~davem/Apache-PerlVINC-0.03/PerlVINC.pm
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Ayhan Ulusoy <ay...@drexel.edu>.
> 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
Re: RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
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. 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.
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).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE : [PATCH] add PERL5LIB to @INC in the correct order
Posted by Ayhan Ulusoy <ay...@drexel.edu>.
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:geoff@modperlcookbook.org]
Envoyé : vendredi 17 octobre 2003 01:56
À : Stas Bekman
Cc : dev@perl.apache.org
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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>> again, that's not required and it doesn't work now anyway - if it's
>>> in %ENV it doesn't need to be passed to take effect. at least that's
>>> what my tests show.
>>
>>
>>
>> That's only true without -T, if -T is on $ENV{PERL5LIB} is ignored.
>>
>> How about the following compromise: we make a special case for
>> 'PerlPassEnv PERL5LIB' if -T is in effect? It works correctly without
>> -T, so we only want to circumvent -T here, as a special case.
>>
>> Actually I'm interested to know why PERl5LIB is ignored on -T, may be
>> the reason is critical enough that we should just respect that perl's
>> feature and leave it alone?
>>
>
> that's my feeling. if the only reason to support PERL5LIB is so that
> users who are already familiar with the syntax can specify their own
> libraries in a way that's familiar (since there are other ways to do it
> with mod_perl, after all), then I see no reason not to follow perl's
> lead here.
>
> if we make a special case, then we're essentially circumventing the
> protection that perl ordinarily guarantees with -T, which could result
> in unforseen consequences. taint mode exists as a protection, so it's
> probably unwise to work around it just because we can.
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 still want to know why PERL5LIB is ignored by perl, I will ask p5p as
perlsec.pod doesn't say anything about it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> again, that's not required and it doesn't work now anyway - if it's in
>> %ENV it doesn't need to be passed to take effect. at least that's
>> what my tests show.
>
>
> That's only true without -T, if -T is on $ENV{PERL5LIB} is ignored.
>
> How about the following compromise: we make a special case for
> 'PerlPassEnv PERL5LIB' if -T is in effect? It works correctly without
> -T, so we only want to circumvent -T here, as a special case.
>
> Actually I'm interested to know why PERl5LIB is ignored on -T, may be
> the reason is critical enough that we should just respect that perl's
> feature and leave it alone?
>
that's my feeling. if the only reason to support PERL5LIB is so that users
who are already familiar with the syntax can specify their own libraries in
a way that's familiar (since there are other ways to do it with mod_perl,
after all), then I see no reason not to follow perl's lead here.
if we make a special case, then we're essentially circumventing the
protection that perl ordinarily guarantees with -T, which could result in
unforseen consequences. taint mode exists as a protection, so it's probably
unwise to work around it just because we can.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> I'm not arguing that - if it's in their %ENV then it will be (and is)
> respected (within the normal limits of -T, that is).
>
> what I'm suggesting is that we remove PerlSetEnv PERL5LIB as a special
> case, the main reason being that PerlSetEnv has the wrong scope for what
> we (and the end-users) want to accomplish.
>
> the only reasonable alternative I can see is adding
> $r->subprocess_env('PERL5LIB') to @INC each time an interpreter is
> selected from the pool, matching request-wide interpreters to a
> per-server setting, while allowing per-phase interpreters to capture a
> per-directory setting. that kind of logic would make it closer to
> Apache::PerlVINC (and increase the overhead, I'm assuming).
>
>> The only requirement we can really add is to ask those users to
>> 'PerlPassEnv PERL5LIB', or even add it to the list of TZ
>> and HOME, that we pass by default. (that and PERLLIB).
>
>
> again, that's not required and it doesn't work now anyway - if it's in
> %ENV it doesn't need to be passed to take effect. at least that's what
> my tests show.
That's only true without -T, if -T is on $ENV{PERL5LIB} is ignored.
How about the following compromise: we make a special case for 'PerlPassEnv
PERL5LIB' if -T is in effect? It works correctly without -T, so we only want
to circumvent -T here, as a special case.
Actually I'm interested to know why PERl5LIB is ignored on -T, may be the
reason is critical enough that we should just respect that perl's feature and
leave it alone?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> right. and that was my point all along - (Perl)SetEnv doesn't work in
>> 2.0. it did work in 1.0, but the syntax is funky since you can
>> PerlSetEnv anywhere, even within a container, so sometimes it works
>> and sometimes it doesn't, depending on when the one-per-request
>> processing happens.
>
>
> it doesn't work because mp2 doesn't do what mp1 did (snippet above)
yes, I know, which is why I said in my earlier email that "as I looked at
implementing it, I can't decide on where to put it, since I never really
liked how it behaved in mp1"
> and
> because in mp2 Perl* directives aren't run immediately as they are
> encountered. It's easy to make a change to make PerlSetEnv PERL5LIB
> special and push it into environ before perl starts.
well, it's more complex than that, and goes back to what I was saying about
the scope of PerlSetEnv not matching the scope of an interpreter -
PerlSetEnv can go anywhere, while interpreter-specific variables are
required on a per-server basis. so, I'm kinda against having a special case
for PerlSetEnv PERL5LIB for reason stated earlier.
>
>>> notice that it doesn't even split path on ':'.
>>
>>
>>
>> yup :)
>>
>> so I'm back to my original suggestion: let's mark (Perl)SetEnv
>> PERL5LIB as deprecated, leave $ENV{PERL5LIB} behaving as perl does
>> automatically (including ignoring under -T), and suggest PerlSwitches
>> -I as the canonical way to add additional paths to @INC from httpd.conf.
>
>
> I'm not convinced that users will be happy about it. If they run their
> own local install of perl libs, they would expect any perl app to
> respect that setting.
I'm not arguing that - if it's in their %ENV then it will be (and is)
respected (within the normal limits of -T, that is).
what I'm suggesting is that we remove PerlSetEnv PERL5LIB as a special case,
the main reason being that PerlSetEnv has the wrong scope for what we (and
the end-users) want to accomplish.
the only reasonable alternative I can see is adding
$r->subprocess_env('PERL5LIB') to @INC each time an interpreter is selected
from the pool, matching request-wide interpreters to a per-server setting,
while allowing per-phase interpreters to capture a per-directory setting.
that kind of logic would make it closer to Apache::PerlVINC (and increase
the overhead, I'm assuming).
> The only requirement we can really add is to ask
> those users to 'PerlPassEnv PERL5LIB', or even add it to the list of TZ
> and HOME, that we pass by default. (that and PERLLIB).
again, that's not required and it doesn't work now anyway - if it's in %ENV
it doesn't need to be passed to take effect. at least that's what my tests
show.
> We probably could
> ask users about it. Or we could do nothing about it, until someone
> complains (while storing the summary of this discussion somewhere in the
> STATUS/todo?).
:)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>> in src/modules/perl/mod_perl.c:
>>
>> /* SetEnv PERL5LIB */
>> if (!MP_INCPUSH(cld)) {
>> char *path = (char *)table_get(r->subprocess_env, "PERL5LIB");
>>
>> if (path) {
>> perl_inc_unshift(path);
>> MP_INCPUSH_on(cld);
>> }
>> }
>
>
> right. and that was my point all along - (Perl)SetEnv doesn't work in
> 2.0. it did work in 1.0, but the syntax is funky since you can
> PerlSetEnv anywhere, even within a container, so sometimes it works and
> sometimes it doesn't, depending on when the one-per-request processing
> happens.
it doesn't work because mp2 doesn't do what mp1 did (snippet above) and
because in mp2 Perl* directives aren't run immediately as they are
encountered. It's easy to make a change to make PerlSetEnv PERL5LIB special
and push it into environ before perl starts.
>> notice that it doesn't even split path on ':'.
>
>
> yup :)
>
> so I'm back to my original suggestion: let's mark (Perl)SetEnv PERL5LIB
> as deprecated, leave $ENV{PERL5LIB} behaving as perl does automatically
> (including ignoring under -T), and suggest PerlSwitches -I as the
> canonical way to add additional paths to @INC from httpd.conf.
I'm not convinced that users will be happy about it. If they run their own
local install of perl libs, they would expect any perl app to respect that
setting. The only requirement we can really add is to ask those users to
'PerlPassEnv PERL5LIB', or even add it to the list of TZ and HOME, that we
pass by default. (that and PERLLIB). We probably could ask users about it. Or
we could do nothing about it, until someone complains (while storing the
summary of this discussion somewhere in the STATUS/todo?).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> if you're seeing something different but following the same steps,
>> then we clearly need some tests to flesh this out, though I'm not sure
>> now how we would undo -T for a single set of tests in the suite.
>
>
> Sorry, you are right, I was looking at the wrong printout. I did:
>
> use Data::Dumper;
> warn Dumper \@INC;
> warn Dumper $ENV{PERL5LIB};
>
> So @INC didn't have it, but $ENV{PERL5LIB} had.
>
> So it's only when PERL5LIB is set outside and PerlPassEnv is used it
> affects mod_perl.
actually, PerlPassEnv isn't required.
> Though since everybody is better off running with -T,
> it doesn't make any difference. The question is whether we should
> support PERL5LIB despite -T or not.
>
> >>> I don't see that in core. I see some special handling for tainting
> >>> in the test suite, though. but you could be right.
> >>
> >> which core? 1 or 2?
>
> In mp1 tt does that regardless tainting:
yes, that I knew. it was the special treatment of -T that I didn't see.
>
> in src/modules/perl/mod_perl.c:
>
> /* SetEnv PERL5LIB */
> if (!MP_INCPUSH(cld)) {
> char *path = (char *)table_get(r->subprocess_env, "PERL5LIB");
>
> if (path) {
> perl_inc_unshift(path);
> MP_INCPUSH_on(cld);
> }
> }
right. and that was my point all along - (Perl)SetEnv doesn't work in 2.0.
it did work in 1.0, but the syntax is funky since you can PerlSetEnv
anywhere, even within a container, so sometimes it works and sometimes it
doesn't, depending on when the one-per-request processing happens.
>
> notice that it doesn't even split path on ':'.
yup :)
so I'm back to my original suggestion: let's mark (Perl)SetEnv PERL5LIB as
deprecated, leave $ENV{PERL5LIB} behaving as perl does automatically
(including ignoring under -T), and suggest PerlSwitches -I as the canonical
way to add additional paths to @INC from httpd.conf.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> if you're seeing something different but following the same steps, then
> we clearly need some tests to flesh this out, though I'm not sure now
> how we would undo -T for a single set of tests in the suite.
Sorry, you are right, I was looking at the wrong printout. I did:
use Data::Dumper;
warn Dumper \@INC;
warn Dumper $ENV{PERL5LIB};
So @INC didn't have it, but $ENV{PERL5LIB} had.
So it's only when PERL5LIB is set outside and PerlPassEnv is used it affects
mod_perl. Though since everybody is better off running with -T, it doesn't
make any difference. The question is whether we should support PERL5LIB
despite -T or not.
>>> I don't see that in core. I see some special handling for tainting
>>> in the test suite, though. but you could be right.
>>
>> which core? 1 or 2?
In mp1 tt does that regardless tainting:
in src/modules/perl/mod_perl.c:
/* SetEnv PERL5LIB */
if (!MP_INCPUSH(cld)) {
char *path = (char *)table_get(r->subprocess_env, "PERL5LIB");
if (path) {
perl_inc_unshift(path);
MP_INCPUSH_on(cld);
}
}
notice that it doesn't even split path on ':'.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Works perfectly fine for me. I removed -T added PerlPassEnv PERL5LIB to
> httpd.conf, changed the apr/pool test to dump @INC, run the tests with:
>
> env PERL5LIB=/tmp t/TEST apr/pool
>
> got /tmp printed out.
but that's different - it's already in your environment, so it's available
when the interpreter is started.
try the same without PerlPassEnv, or use PerlSetEnv without using it on the
command line and see what happens.
you comment later that you did indeed try this, as did I, and I cannot
reproduce your results. here's what I'm doing
- comment out PerlSwitches -wT from extra.conf.in
- insert PerlSetEnv PERL5LIB /foo in httpd.conf
- add @INC dump in t/response/TestAPR/pool.pm
then, if I run
$ t/TEST t/apr/pool.t -v
I get no /foo in my @INC in the error_log
if I run
$ PERL5LIB=/bar t/TEST t/apr/pool.t -v
I get /bar in my @INC in the error_log
if you're seeing something different but following the same steps, then we
clearly need some tests to flesh this out, though I'm not sure now how we
would undo -T for a single set of tests in the suite.
>>
>> I don't see that in core. I see some special handling for tainting in
>> the test suite, though. but you could be right.
>
>
> which core? 1 or 2?
mp1
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> Geoffrey Young wrote:
>>
>>>
>>>>> and of course need to fix that in mp2.
>>>
>>>
>>>
>>>
>>>> I'll tacked the mp2 bits this week.
>>>
>>>
>>>
>>>
>>> just looking at it now...
>>>
>>> it seems that mp2 doesn't respect (Perl)SetEnv PERL5LIB - I can't
>>> find it in the code and can't get it to work in the tests.
>>
>>
>>
>> It's not mp2, it's perl. See the last para:
>
>
> I'm aware of what PERL5LIB is, thanks :)
I know, I was just pointing out the -T issue.
>> comment out PerlSwitches -T and it'll appear.
>
>
> it doesn't.
>
> and it doesn't because the issue I'm raising is a mod_perl one, and not
> a perl one. see below.
Works perfectly fine for me. I removed -T added PerlPassEnv PERL5LIB to
httpd.conf, changed the apr/pool test to dump @INC, run the tests with:
env PERL5LIB=/tmp t/TEST apr/pool
got /tmp printed out.
>> > as I looked at implementing it, I can't decide on where to put it,
>> since
>> > I never really liked how it behaved in mp1 (as a pseudo-global that
>> > really couldn't be set on a per-<Location> basis even though it's
>> syntax
>> > allowed for it).
>> >
>> > so, my thought now is to abandon SetEnv PERL5LIB and rely on
>> > PerlSwitches -I exclusively for adding @INC paths to the
>> interpreter via
>> > httpd.conf.
>> >
>> > sound ok?
>>
>> mp1 has a special code to circumvent perl's ignorance of PERL5LIB
>> under -T. We could copy it over, but I'd suggest to run it only at the
>> server startup (only if we detect that -T is On) and never touch it
>> again. We probably need to support that, so that it won't give users a
>> reason not to use -T.
>
>
>
> I don't see that in core. I see some special handling for tainting in
> the test suite, though. but you could be right.
which core? 1 or 2?
> nevertheless, the issue I'm talking about is that using (Perl)SetEnv
> only populates the subprocess_env table, not %ENV, and if %ENV ever does
> get populated with the contents of subprocess_env (and it may not under
> some circumstances) it's too late to have PERL5LIB recognized by the
> perl interpreter, since it's already running. this is why mp1 manually
> adds the PERL5LIB from r->subprocess_env to @INC.
Just tested, $ENV{PERL5LIB} is populated alright. either with:
PerlPassEnv PERL5LIB
and setting PERL5LIB env var outside. or with:
PerlSETEnv PERL5LIB /tmp
a dump of @INC, proves that it works just fine.
> the problem with mp1, though, is that
>
> SetEnv PERL5LIB /foo
>
> can occur on a per-<Location> basis. the result is that people _think_
> they are setting PERL5LIB for a given uri but they aren't, and it fails
> silently.
right.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>
>>>> and of course need to fix that in mp2.
>>
>>
>>
>>> I'll tacked the mp2 bits this week.
>>
>>
>>
>> just looking at it now...
>>
>> it seems that mp2 doesn't respect (Perl)SetEnv PERL5LIB - I can't find
>> it in the code and can't get it to work in the tests.
>
>
> It's not mp2, it's perl. See the last para:
I'm aware of what PERL5LIB is, thanks :)
>
> comment out PerlSwitches -T and it'll appear.
it doesn't.
and it doesn't because the issue I'm raising is a mod_perl one, and not a
perl one. see below.
>
> > as I looked at implementing it, I can't decide on where to put it, since
> > I never really liked how it behaved in mp1 (as a pseudo-global that
> > really couldn't be set on a per-<Location> basis even though it's syntax
> > allowed for it).
> >
> > so, my thought now is to abandon SetEnv PERL5LIB and rely on
> > PerlSwitches -I exclusively for adding @INC paths to the interpreter via
> > httpd.conf.
> >
> > sound ok?
>
> mp1 has a special code to circumvent perl's ignorance of PERL5LIB under
> -T. We could copy it over, but I'd suggest to run it only at the server
> startup (only if we detect that -T is On) and never touch it again. We
> probably need to support that, so that it won't give users a reason not
> to use -T.
I don't see that in core. I see some special handling for tainting in the
test suite, though. but you could be right.
nevertheless, the issue I'm talking about is that using (Perl)SetEnv only
populates the subprocess_env table, not %ENV, and if %ENV ever does get
populated with the contents of subprocess_env (and it may not under some
circumstances) it's too late to have PERL5LIB recognized by the perl
interpreter, since it's already running. this is why mp1 manually adds the
PERL5LIB from r->subprocess_env to @INC.
the problem with mp1, though, is that
SetEnv PERL5LIB /foo
can occur on a per-<Location> basis. the result is that people _think_ they
are setting PERL5LIB for a given uri but they aren't, and it fails silently.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>> and of course need to fix that in mp2.
>
>
>> I'll tacked the mp2 bits this week.
>
>
> just looking at it now...
>
> it seems that mp2 doesn't respect (Perl)SetEnv PERL5LIB - I can't find
> it in the code and can't get it to work in the tests.
It's not mp2, it's perl. See the last para:
PERL5LIB A list of directories in which to look for Perl library
files before looking in the standard library and the cur-
rent directory. Any architecture-specific directories
under the specified locations are automatically included if
they exist. If PERL5LIB is not defined, PERLLIB is used.
Directories are separated (like in PATH) by a colon on
unixish platforms and by a semicolon on Windows (the proper
path separator being given by the command "perl
-V:path_sep").
When running taint checks (either because the program was
running setuid or setgid, or the -T switch was used), nei-
ther variable is used. The program should instead say:
use lib "/my/directory";
comment out PerlSwitches -T and it'll appear.
> as I looked at implementing it, I can't decide on where to put it, since
> I never really liked how it behaved in mp1 (as a pseudo-global that
> really couldn't be set on a per-<Location> basis even though it's syntax
> allowed for it).
>
> so, my thought now is to abandon SetEnv PERL5LIB and rely on
> PerlSwitches -I exclusively for adding @INC paths to the interpreter via
> httpd.conf.
>
> sound ok?
mp1 has a special code to circumvent perl's ignorance of PERL5LIB under -T. We
could copy it over, but I'd suggest to run it only at the server startup (only
if we detect that -T is On) and never touch it again. We probably need to
support that, so that it won't give users a reason not to use -T.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> and of course need to fix that in mp2.
> I'll tacked the mp2 bits this week.
just looking at it now...
it seems that mp2 doesn't respect (Perl)SetEnv PERL5LIB - I can't find it in
the code and can't get it to work in the tests.
as I looked at implementing it, I can't decide on where to put it, since I
never really liked how it behaved in mp1 (as a pseudo-global that really
couldn't be set on a per-<Location> basis even though it's syntax allowed
for it).
so, my thought now is to abandon SetEnv PERL5LIB and rely on PerlSwitches -I
exclusively for adding @INC paths to the interpreter via httpd.conf.
sound ok?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> OK, so 1.29 is out, we can put your patch in.
>
>
> I know I was +1 before, but now that we're all a bit more enlightened as
> to PERL5LIB and its implications, I think we ought to reconsider.
>
> my reasons against altering _anything_ about PERL5LIB behavior in 1.0
> would be
>
> - altering the existing, stable codebase for little benefit. nobody
> else has reported using lib separators (":") or wanting arch libs
> included in, what, 6+ years?
>
> - we probably shouldn't be supporting it at all
>
> just my $0.02. it's not a veto or anything, but I'm really hesitant to
> play around with this simply because, even though the changes is simple,
> we still may introduce bugs that hurt existing users of PERL5LIB. and
> that's not good at this point.
I'd be tempted to put that change in, exactly because nobody has complained so
far, which can be interpreted that nobody was relying on that feature or
questions would be raised.
In the mp1 guide: "Installation Without Superuser Privileges"
http://perl.apache.org/docs/1.0/guide/install.html#Installation_Without_Superuser_Privileges
The section:
"Making Your Scripts Find the Locally Installed Modules"
http://perl.apache.org/docs/1.0/guide/install.html#Making_Your_Scripts_Find_the_Locally_Installed_Modules
uses PERL5LIB with multiple entries and it explicitly specifies arch libs.
though the order of insertion didn't matter in that particular case.
Notice that if we use the lib pragma, it'll still do the right thing even if
PERL5LIB has already explicitly specified arch libs, as the guide suggestes.
I guess Simon could help us here as neither I have a strong opinion about this
change. Do you think, Simon, that we should change the existing behavior or
just document the way it works? Either way works for me.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> OK, so 1.29 is out, we can put your patch in.
I know I was +1 before, but now that we're all a bit more enlightened as to
PERL5LIB and its implications, I think we ought to reconsider.
my reasons against altering _anything_ about PERL5LIB behavior in 1.0 would be
- altering the existing, stable codebase for little benefit. nobody else
has reported using lib separators (":") or wanting arch libs included in,
what, 6+ years?
- we probably shouldn't be supporting it at all
just my $0.02. it's not a veto or anything, but I'm really hesitant to play
around with this simply because, even though the changes is simple, we still
may introduce bugs that hurt existing users of PERL5LIB. and that's not
good at this point.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Simon Flack wrote:
> On Mon, 06 Oct 2003 15:37:12 -0400, Geoffrey Young wrote
>
>>>Should we try to squeeze it into 1.29? If so do we need another release
>>>candidate? Since we need 1.29 out asap, because of the bug in 5.8.1, I
>>>suggest that we release 1.29 as it is now. Then hopefully we will
>>>release 1.30 some time soon (including the PERL5LIB fix). I know there
>>>are quite a few patches that Philippe has planned to put in and we want
>>>them to sit in the cvs for some time to get people time to test it out
>>>well.
>>
>>my advice would be to get 1.29 out soon, as it will be the first
>>stable version of mod_perl specifically for 5.8.1.
>>
>>release 1.30 can come with those patches, and be released at a much
>>more leisurely pace
>>
>>--Geoff
>
>
> I'm happy with that. There's also another problem with PERL5LIB that I've
> noticed, but not fixed because there's an easy workaround:
>
> According to perlrun(1), architechture subfolders are added to @INC as well:
>
> PERL5LIB
>
> A colon-separated list of directories in which to look for
> Perl library files before looking in the standard library
> and the current directory. Any architecture-specific
> directories under the specified locations are automatically
> included if they exist.
>
> For example on my dev box, setting PERL5LIB to '/home/simonflk/perllib'
> should add '/home/simonflk/perllib/i686-linux' if it exists.
>
> The simple and obvious workaround is to add that to PERL5LIB. But it would be
> nice for it to behave as documented in perl. If the other fix to PERL5LIB is
> scheduled for v1.30, it makes sense to fix that for the same release. When I
> get some time I'll send in a patch.
OK, so 1.29 is out, we can put your patch in. Re: arch dirs, I think it's a
"recent" behavior (5.6x) and when that mp1 code was written (many years ago)
it wasn't there. So would you consider to submit a new patch that performs the
arch lookup as well and we will commit it at once?
My suggestion would be to simply use the lib pragma and delegate the job of
looking up the arch dirs to it. So all we need to do is :
use lib split /$separator/, $ENV{PERL5LIB};
though via C (you can use eval_pv to eval the above string).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Simon Flack <sf...@flacks.net>.
On Mon, 06 Oct 2003 15:37:12 -0400, Geoffrey Young wrote
> > Should we try to squeeze it into 1.29? If so do we need another release
> > candidate? Since we need 1.29 out asap, because of the bug in 5.8.1, I
> > suggest that we release 1.29 as it is now. Then hopefully we will
> > release 1.30 some time soon (including the PERL5LIB fix). I know there
> > are quite a few patches that Philippe has planned to put in and we want
> > them to sit in the cvs for some time to get people time to test it out
> > well.
>
> my advice would be to get 1.29 out soon, as it will be the first
> stable version of mod_perl specifically for 5.8.1.
>
> release 1.30 can come with those patches, and be released at a much
> more leisurely pace
>
> --Geoff
I'm happy with that. There's also another problem with PERL5LIB that I've
noticed, but not fixed because there's an easy workaround:
According to perlrun(1), architechture subfolders are added to @INC as well:
PERL5LIB
A colon-separated list of directories in which to look for
Perl library files before looking in the standard library
and the current directory. Any architecture-specific
directories under the specified locations are automatically
included if they exist.
For example on my dev box, setting PERL5LIB to '/home/simonflk/perllib'
should add '/home/simonflk/perllib/i686-linux' if it exists.
The simple and obvious workaround is to add that to PERL5LIB. But it would be
nice for it to behave as documented in perl. If the other fix to PERL5LIB is
scheduled for v1.30, it makes sense to fix that for the same release. When I
get some time I'll send in a patch.
Thanks
--simonflk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Should we try to squeeze it into 1.29? If so do we need another release
> candidate? Since we need 1.29 out asap, because of the bug in 5.8.1, I
> suggest that we release 1.29 as it is now. Then hopefully we will
> release 1.30 some time soon (including the PERL5LIB fix). I know there
> are quite a few patches that Philippe has planned to put in and we want
> them to sit in the cvs for some time to get people time to test it out
> well.
my advice would be to get 1.29 out soon, as it will be the first stable
version of mod_perl specifically for 5.8.1.
release 1.30 can come with those patches, and be released at a much more
leisurely pace
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> On the second thought, chances are that nobody has been using a
>> multiple-paths PERL5LIB, otherwise they would have complained like you
>> did. So if nobody objects and we agree that the current behavior is
>> buggy, +1 for your patch.
>>
>> So what do you think, fix it? or document it?
>>
>> and of course need to fix that in mp2.
>
>
> +1 on fixing it to behave properly in mp1.
>
> I'll tacked the mp2 bits this week.
Should we try to squeeze it into 1.29? If so do we need another release
candidate? Since we need 1.29 out asap, because of the bug in 5.8.1, I suggest
that we release 1.29 as it is now. Then hopefully we will release 1.30 some
time soon (including the PERL5LIB fix). I know there are quite a few patches
that Philippe has planned to put in and we want them to sit in the cvs for
some time to get people time to test it out well.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> On the second thought, chances are that nobody has been using a
> multiple-paths PERL5LIB, otherwise they would have complained like you
> did. So if nobody objects and we agree that the current behavior is
> buggy, +1 for your patch.
>
> So what do you think, fix it? or document it?
>
> and of course need to fix that in mp2.
+1 on fixing it to behave properly in mp1.
I'll tacked the mp2 bits this week.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Simon Flack wrote:
> On Tue, 30 Sep 2003 11:49:57 -0700, Stas Bekman wrote
>
>>Simon Flack wrote:
>>
>>>Problem:
>>> at the beggining of each request PERL5LIB is prepended to @INC in
>>> reverse order. E.g.:
>>> SetEnv PERL5LIB "one:two:three:four"
>>> results in this:
>>> @INC = ('four', 'three', 'two', 'one', '/usr....', '...');
>>>
>>>Environment:
>>> Tested with perl 5.6.1, mod_perl 1.27 and 1.28
>>>
>>>A patch is attached to src/modules/perl/perl_util.c that adds the
>
> PERL5LIB
>
>>>variables in the correct order.
>>
>>Thank you Simon.
>>
>>It's a bug indeed. However I think we can't change this
>>functionality in mp1 at this point, since it'll break other people's
>>setups which rely on the current behavior. We probably should
>>document this mis-feature.
>
>
> Stas,
>
> That's fine. Although the behaviour has changed as recently as v1.27 where
> previously the contents of PERL5LIB were pushed onto @INC rather that
> unshifted.
Well, the fix in 1.27 was different:
PERL5LIB support now properly unshifts paths into @INC rather than push
[Tatsuhiko Miyagawa <mi...@edge.co.jp>]
before 1.27, PERL5LIB was getting appended to @INC, instead of being
prepended. As a side effect it got the values in PERL5LIB reversed, but at
least they are coming in before the hardcoded @INC.
> The problem with the current behaviour is that you need a special case when
> running under mod_perl. In our set up, we test our scripts as CGIs and with
> Apache::Registry and it's nice to be able to set PERL5LIB in one place rather
> than two.
On the second thought, chances are that nobody has been using a multiple-paths
PERL5LIB, otherwise they would have complained like you did. So if nobody
objects and we agree that the current behavior is buggy, +1 for your patch.
So what do you think, fix it? or document it?
and of course need to fix that in mp2.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Simon Flack <sf...@flacks.net>.
On Tue, 30 Sep 2003 11:49:57 -0700, Stas Bekman wrote
> Simon Flack wrote:
> > Problem:
> > at the beggining of each request PERL5LIB is prepended to @INC in
> > reverse order. E.g.:
> > SetEnv PERL5LIB "one:two:three:four"
> > results in this:
> > @INC = ('four', 'three', 'two', 'one', '/usr....', '...');
> >
> > Environment:
> > Tested with perl 5.6.1, mod_perl 1.27 and 1.28
> >
> > A patch is attached to src/modules/perl/perl_util.c that adds the
PERL5LIB
> > variables in the correct order.
>
> Thank you Simon.
>
> It's a bug indeed. However I think we can't change this
> functionality in mp1 at this point, since it'll break other people's
> setups which rely on the current behavior. We probably should
> document this mis-feature.
Stas,
That's fine. Although the behaviour has changed as recently as v1.27 where
previously the contents of PERL5LIB were pushed onto @INC rather that
unshifted.
The problem with the current behaviour is that you need a special case when
running under mod_perl. In our set up, we test our scripts as CGIs and with
Apache::Registry and it's nice to be able to set PERL5LIB in one place rather
than two.
> Please use this as a workaround:
>
> my $PERL5LIB = "one:two:three:four";
> unshift @INC, $_ for reverse split /:/, $PERL5LIB;
We've done something like this, that works in mod_perl and non-mod_perl
environments:
SetEnv PERL5LIB one:two:three:four:three:two:one
Of course we have to explain that with a comment in case someone comes along
in a few months and thinks "I'll clean up that duplication"
We'll probably just apply the patch to our departmental servers and document
that in the build instructions.
Thanks
--simonflk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] add PERL5LIB to @INC in the correct order
Posted by Stas Bekman <st...@stason.org>.
Simon Flack wrote:
> Problem:
> at the beggining of each request PERL5LIB is prepended to @INC in
> reverse order. E.g.:
> SetEnv PERL5LIB "one:two:three:four"
> results in this:
> @INC = ('four', 'three', 'two', 'one', '/usr....', '...');
>
> Environment:
> Tested with perl 5.6.1, mod_perl 1.27 and 1.28
>
> A patch is attached to src/modules/perl/perl_util.c that adds the PERL5LIB
> variables in the correct order.
Thank you Simon.
It's a bug indeed. However I think we can't change this functionality in mp1
at this point, since it'll break other people's setups which rely on the
current behavior. We probably should document this mis-feature.
We can fix it in mp2, which I'm quite sure has the same problem.
Please use this as a workaround:
my $PERL5LIB = "one:two:three:four";
unshift @INC, $_ for reverse split /:/, $PERL5LIB;
or something like that, from your startup.pl or using a <Perl> </Perl> section
in httpd.conf.
> Also attached is a test script and .htaccess that demonstrate the bug.
>
> Notes:
> There might be a more elegent way of doing it.
> Apologies if the patch doesn't conform to the style guide - couldn't
> find it, and couldn't work out what indenting to use from looking.
There is none for mp1, which is a mess. the mp2 code style is much better and
conforming to a single style.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org