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:[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]
