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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
