... snip ...
Guilty as charged, but I said that in first place ;)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
