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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
