This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: <modperl@apache.org> From: "Alex Harper" <aharper@broadjump.com> Subject: Setting PerlRequire in a <Perl> section Date: Wed, 19 Sep 2001 16:41:07 -0500 Hi, I'm trying to configure a PerlRequire directive in a <Perl> section of an .htaccess file. This is done so that I can have several directories (one per VirtualHost) load a different PerlRequire startup without resorting to absolute paths for the startup for each VirtualHost. Since FindBin doesn't work for much of anything under mod_perl the solution I'm trying in the .htaccess file is roughly: <Perl> my $dirroot = $0; $dirroot = s/\.htaccess$//; $PerlRequire = $dirroot . "modperlstartup.pl"; </Perl> However this results in the server spinning off into never-never land as soon as the first mod_perl enabled CGI from the directory is loaded. If I load the PerlRequire outside the perl section (using the exact absolute path generated by the code above) everything is fine. Does anyone have any suggestions? Is it safe to add a PerlRequire in a <Perl> section? I see no mention of it anywhere, but then again I also see no examples that do it. More generally is there a better/correct way to do this? All the examples I can find in Stas Bekman's (excellent BTW) guide always use absolute paths for the startup files and any "use lib" pragmas. What I really need is a way to modify the path to the startup and the path to lib on the basis of the VirtualHost and I'd like to avoid hardcoding the paths. === To: Alex Harper <aharper@broadjump.com> From: Stas Bekman <stas@stason.org> Subject: Re: Setting PerlRequire in a <Perl> section Date: Thu, 20 Sep 2001 22:37:26 +0800 Alex Harper wrote: > Hi, > > I'm trying to configure a PerlRequire directive in a <Perl> section of > an .htaccess file. This is done so that I can have several directories > (one per VirtualHost) load a different PerlRequire startup without > resorting to absolute paths for the startup for each VirtualHost. > > Since FindBin doesn't work for much of anything under mod_perl the > solution I'm trying in the .htaccess file is roughly: > <Perl> > my $dirroot = $0; > $dirroot = s/\.htaccess$//; > $PerlRequire = $dirroot . "modperlstartup.pl"; > </Perl> > > However this results in the server spinning off into never-never land as > soon as the first mod_perl enabled CGI from the directory is loaded. If > I load the PerlRequire outside the perl section (using the exact > absolute path generated by the code above) everything is fine. > > Does anyone have any suggestions? Is it safe to add a PerlRequire in a > <Perl> section? I see no mention of it anywhere, but then again I also > see no examples that do it. > > More generally is there a better/correct way to do this? All the > examples I can find in Stas Bekman's (excellent BTW) guide always use > absolute paths for the startup files and any "use lib" pragmas. What I > really need is a way to modify the path to the startup and the path to > lib on the basis of the VirtualHost and I'd like to avoid hardcoding the > paths. mod_perl 2.0 has solved these problems already, but it's not in production yet :) Have you read this one? http://perl.apache.org/guide/config.html#Is_There_a_Way_to_Modify_INC_on You probably need to use Apache::PerlVINC, but it's not very efficient. === To: "Stas Bekman" <stas@stason.org> From: "Alex Harper" <aharper@broadjump.com> Subject: RE: Setting PerlRequire in a <Perl> section Date: Thu, 20 Sep 2001 23:19:00 -0500 >mod_perl 2.0 has solved these problems already, but it's not in >production yet :) Well that give me something to look forward to :-) >Have you read this one? >http://perl.apache.org/guide/config.html#Is_There_a_Way_to_Modify_INC_o n >You probably need to use Apache::PerlVINC, but it's not very efficient. Actually, yes, I had. PerlVINC is not really what I needed, the goal was not to reload %INC per VirtualHost, the need was to have a single PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC would work). Ordinary this would have been done with something like 'use lib "$FindBin::Bin/lib/", but since that doesn't work under mod_perl I was toying with using <Perl> sections. For the record the problem was the line: $PerlRequire = $somepath; Which needed to be: push @PerlRequire, $somepath; Although why the previous version set the server spinning off I never could figure out. It happened even with Apache::Server::StrictPerlSections on. In any case I've settled on absolute paths just like the examples. This increases the maintenance costs with multiple startup scripts, but solves the problem in the most obvious way. Maybe this will be easier in mod_perl 2.0? ==== To: Alex Harper <aharper@broadjump.com> From: Stas Bekman <stas@stason.org> Subject: Re: Setting PerlRequire in a <Perl> section Date: Fri, 21 Sep 2001 12:52:54 +0800 Alex Harper wrote: > > >mod_perl 2.0 has solved these problems already, but it's not in > > >production yet :) > > Well that give me something to look forward to :-) > > >Have you read this one? > > >>http://perl.apache.org/guide/config.html#Is_There_a_Way_to_Modify_INC_o >> > n > >You probably need to use Apache::PerlVINC, but it's not very > efficient. > > > Actually, yes, I had. PerlVINC is not really what I needed, the goal was > not to reload %INC per VirtualHost, the need was to have a single > PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC > would work). Ordinary this would have been done with something like 'use > lib "$FindBin::Bin/lib/", but since that doesn't work under mod_perl I > was toying with using <Perl> sections. > > For the record the problem was the line: > $PerlRequire = $somepath; > Which needed to be: > push @PerlRequire, $somepath; This won't work as you have seen already. If you don't mind reloading the libs at run time, you can always call do() on FindBin which will force the reload of all its internals. > Although why the previous version set the server spinning off I never > could figure out. It happened even with > Apache::Server::StrictPerlSections on. > > In any case I've settled on absolute paths just like the examples. This > increases the maintenance costs with multiple startup scripts, but > solves the problem in the most obvious way. > > Maybe this will be easier in mod_perl 2.0? All I can tell you is that it works already :) and it's very easy. Now let's see how soon httpd 2.0 gets released and how soon we get mod_perl 2.0 out (which of course depends on Apache's release) ==== To: "Alex Harper" <aharper@broadjump.com>, "Stas Bekman" <stas@stason.org> From: "Perrin Harkins" <perrin@elem.com> Subject: Re: Setting PerlRequire in a <Perl> section Date: Fri, 21 Sep 2001 09:06:02 -0400 > Actually, yes, I had. PerlVINC is not really what I needed, the goal was > not to reload %INC per VirtualHost, the need was to have a single > PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC > would work). Ordinary this would have been done with something like 'use > lib "$FindBin::Bin/lib/", but since that doesn't work under mod_perl I > was toying with using <Perl> sections. It sounds like maybe you were not understanding that in the mod_perl 1.x series there is only 1 Perl interpreter shared between all VirtualHosts (they are virtual, after all). That means there can only be one @INC for all VirtualHosts as well. Things like PerlVINC cheat by messing with @INC on each request. === To: "Perrin Harkins" <perrin@elem.com>, "Stas Bekman" <stas@stason.org> From: "Alex Harper" <aharper@broadjump.com> Subject: RE: Setting PerlRequire in a <Perl> section Date: Fri, 21 Sep 2001 09:32:55 -0500 I understood the limitation of the single interpreter, the problem again was to append to @INC per VirtualHost. For example, Application A: running on server 1 has its lib directory at /data/appA/lib/. Its lib packages are in namespace "AppA::" (to prevent overlap in the single Perl interpreter). Application B: running on server 1 has its lib directory at /opt/appB/server/lib. Its lib packages are in namespace "AppB::". The same applications when deployed on server 2, might or might not have the same absolute path to their lib directory. So, for example AppA's lib on server2 might live at /data4/servers/AppA/lib. The historical reason for the differences in path aren't important, just assume I can't fix them :-). Since all app's are segregated into namespaces for their packages, a single interpreter is OK, there is no overlap (we made that change specifically to support mod_perl). The goal was to be able to checkout the application source from our CVS repository, "Include" its "app.httpd.conf" from the main httpd.conf, and be ready to go, with the absolute path for each application's lib directory appended to @INC for StatINC to work. Obviously in order for that to work each App's startup.pl would need to be able to determine its path as it is PerlRequire'd, so it can build the needed path to the lib directory. Wihtout FindBin this doesn't work under mod_perl. <Perl> sections appeared to be capable of doing it (since the app.httpd.conf was located in the source tree of the app we could use $0 to find the path to app.httpd.conf) but attempting to do too much in a <Perl> section seemed to constantly cause breaks (I eventually gave up). As I mentioned previously we switched to absolute paths in the per-application startup.pl file. Its a pain to maintain a per-server times per-application list of lib paths, but that fixes us until I get to see what mod_perl 2.0 has in store for me :-) === To: "Alex Harper" <aharper@broadjump.com> From: "Perrin Harkins" <perrin@elem.com> Subject: Re: Setting PerlRequire in a <Perl> section Date: Fri, 21 Sep 2001 11:29:31 -0400 > I understood the limitation of the single interpreter, the problem again > was to append to @INC per VirtualHost. It's confusing when you say that, since there's only one @INC for everything. I'm interpreting this as meaning that you have a bunch of applications with different install directories and you want them all to go in the global @INC. > The goal was to be able to checkout the application source from our CVS > repository, "Include" its "app.httpd.conf" from the main httpd.conf, and > be ready to go, with the absolute path for each application's lib > directory appended to @INC for StatINC to work. How do you avoid hard-coding the paths to app.httpd.conf then? If you're already hard-coding that path on each server, you should be able to just make everything else relative to that. Is that what you were trying to do with your original post? That code would work fine if you change $PerlRequire to a straight 'require'. They do the same thing. <Perl> my $dirroot = $0; $dirroot = s/\.htaccess$//; require ($dirroot . 'modperlstartup.pl'); </Perl> > As I mentioned previously we switched to absolute paths in the > per-application startup.pl file. Its a pain to maintain a per-server > times per-application list of lib paths, but that fixes us until I get > to see what mod_perl 2.0 has in store for me :-) Well, what Stas was talking about with mod_perl 2 was just having different Perl interpreters (with different @INCs) per VirtualHost, which actually doesn't sound like it has much to do with your problem. I still don't understand what problem you're trying to solve well enough to give good advice, but configuration management issues are commonly handled through an installation process that sets local paths. The last time I had to do that for a mod_perl app, we used Template Toolkit to generate our httpd.conf and startup.pl with local paths during the install. For simpler localization, you could just use a couple of substitutions, or you could try playing with MakeMaker. === To: "Perrin Harkins" <perrin@elem.com> From: "Alex Harper" <aharper@broadjump.com> Subject: RE: Setting PerlRequire in a <Perl> section Date: Fri, 21 Sep 2001 15:41:07 -0500 > > > I understood the limitation of the single interpreter, the > problem again > > was to append to @INC per VirtualHost. > > It's confusing when you say that, since there's only one @INC for > everything. I'm interpreting this as meaning that you have a bunch of > applications with different install directories and you want > them all to go > in the global @INC. Sorry for the confusion. Your interpretation is correct. I wish to add several different paths to the common global @INC, one per application. > How do you avoid hard-coding the paths to app.httpd.conf > then? If you're > already hard-coding that path on each server, you should be > able to just > make everything else relative to that. Is that what you were > trying to do > with your original post? That code would work fine if you change > $PerlRequire to a straight 'require'. They do the same thing. Exactly, the only abs path we would like is the per-server master httpd.conf. The difference (or lack thereof) between PerlRequire and require in a <Perl> section wa lost on me. Thanks for the tip. > Well, what Stas was talking about with mod_perl 2 was just > having different > Perl interpreters (with different @INCs) per VirtualHost, > which actually > doesn't sound like it has much to do with your problem. Not directly, no it wouldn't, although I actually would like to see this for other issues we had earlier (which we solved by moving all our packages into unique namespaces). I'll look into the other configuration solution you mentioned, although I expect they provide more than we really need for these applications. ===