I just started getting onto the one-perl-per-app train. By default, Configure wants to set up an installation with a deeply nested directory layout so as much as possible can be shared across installs. I don’t care about that – having completely separate installs is quite affordable these days. So all that hierarchy is merely annoying and serves no useful purpose, and I would prefer to simply have all modules in ./lib and all XS components in ./archlib below the root directory of the installation, without any further nesting for different Perl versions, system architectures and packaging authorities.
But figuring out exactly how to get Perl’s Configure to give me I want took almost two hours of fiddling and research (and the final hint came from a rather tangential archived mailing list post).
So I thought I would jot the recipe down here:
PREFIX=$HOME/perl/5.10.0 # pick any root directory you like
sh Configure -des \
-Dprefix=$PREFIX \
-Dinc_version_list=none \
-Dprivlib=$PREFIX/lib \
-Darchlib=$PREFIX/archlib \
-Dsitearch=$PREFIX/archlib \
-Dsitelib=$PREFIX/lib
The maddening part was to figure out that inc_version_list must be none, otherwise the sitearch and sitelib settings will be ignored and Configure will generate the default deeply nested layout for them.
I have to say that Perl requires rather a lot of work to beat it into submission to my preferences…
Re:extended to mod_perl
Aristotle on 2008-10-29T09:33:50
Hmm, that’s a good question. I don’t know, nor am I likely to figure anything out. My own tendency has been to treat mod_perl as something to use specifically for writing Apache modules, but to not use Apache modules as a web app deployment platform.
For that I now prefer an in-process HTTP implementation – in this case, Catalyst::Engine::HTTP::Prefork – along with whatever reverse proxy is most handy. I also don’t bother with highly involved configurations for serving static files, I just use Catalyst::Plugin::Static::Simple (which you’re not supposed to do, according to orthodoxy) and let the reverse proxy take care of serving those files without backend server load. The overall result is a drastic simplification of the deployment process, accompanied by a significant increase in flexibility, with the added bonus that the development system setup differs from the production box only in the absence of a reverse proxy. (And it’s not different to remove that difference – you can set up a reverse proxy on a dev box quite easily if you need to, and you can also probe the app server on the production box without going through the reverse proxy.) Process model wise this setup is very similar to the typical configuration of a slim Apache that serves static files and reverse proxies to a mod_perl-enabled Apache that runs the app, just a lot less heavyweight.
So I have lost almost all of my interest in mod_perl.
Re: Aristotle's web app deployment model
markjugg on 2008-11-20T02:18:47
Thanks for sharing your techniques. How do you handle some of the functions typically be handled by Apache in web application, for example, rewrites, redirects and aliases (allowing a directory outside the web server root to appear within it)?Re: Aristotle's web app deployment model
Aristotle on 2008-11-20T03:01:25
All decent dedicated reverse proxies have features on par with mod_rewrite, so it’s not hard to adapt the practice accordingly. However, rather than using such features for everything I have actually come to consider some of that work, esp. redirects, as part of the app itself – f.ex. redirects to support the URI structure of an old version of the app. So I write logic for them in the app using the framework’s features. The reverse proxy is the place for rewrites that concern the integration of an app instance into a larger overall site.
This separation makes deployed instances self-contained and portable. It also makes it easier to a) keep redirect logic for old or alternative URI structures under version control while b) not mixing the version-controlled logic with deployment specifics concerning other parts of the site. Finally, I find that the combination of HTTP on the wire all the way and careful separation of responsibilities results in tremendous flexibility: you can set up your infrastructure any way you like/need without it affecting the outward face of your site at all. (Which is the essence of REST: near-zero coupling.)
Re: Aristotle's web app deployment model (Thanks)
markjugg on 2008-11-21T19:34:01
Thanks, for the reply.
I'm coming to the same conclusion about the benefit of self-contained apps, and having a maximal amount under source control, compared to creating a coupling between app changes and web server configuration.