Why would you optimize for installation over development? Seems like you do the latter a lot more than the former. :)
Besides which, releasing from a single directory hierarchy is just a matter of checking out from version control (if you're willing to have svn etc. on your production boxes), or rsyncing from your staging boxes. Jon On Mar 11, 2009, at 12:17 PM, Dave Rolsky wrote: > On Wed, 11 Mar 2009, Jonathan Swartz wrote: > >>> Typically, where would you place such a module in your filesystem? >>> Let's >>> say the apache document root is /var/www/myapp, would you create a >>> ./lib/perl/MyApp/Constants.pm off this directory? >> >> I prefer to have everything necessary for a web site - components, >> libraries, scripts, configuration files - under a single directory >> (the "environment root"). That makes it easy to put the entire site >> under version control, migrate it, etc. >> >> Take a look at the way Catalyst sets up a project, or the source of >> the Mason web site (http://www.masonhq.com/?SourceForThisSite), for >> examples. > > That certainly makes for a good dev setup, but that's kind of > orthogonal > to how you install. > > I see a couple possibilities: > > 1. Do it how Perl and/or the distro does it. Modules go in the local > module dir, scripts where Perl puts scripts from CPAN tarballs. Then > make > something sane up for templates, images, etc. On a Debian system, > the FHS > will guide you to some combination of /usr/local/share, /var/lib, > /var/cache, etc. > > 2. Put everything under /opt/MyApp (or /usr/local/MyApp, or whatever). > This certainly makes installing easy, but it might make configuring > the > app to be served a little more complex, because your web server > won't look > for anything there by default. Also, you may end up mixing temporary > writable stuff (Mason cache files) stuff that should be read-only > (libraries and static content, etc), which seems a bit wrong to me. > > 3. Make packages for everything and do _everything_ like the distro > does > it. For repeatable, easy to automate deployments across many boxes, > this > is the way to go. You create your deb/rpm server and then point your > servers at it. Releasing consists of uploading new packages and then > having each server pull them down (something like clusterssh works > well > here). > > > For most of my stuff, I've done #1, which is fine for small apps > that live > on one or two boxes. If I was working on something with bigger > ambitions, > I'd put the effort in for #3. > > > -dave > > /*============================================================ > http://VegGuide.org http://blog.urth.org > Your guide to all that's veg House Absolute(ly Pointless) > ============================================================*/ > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Mason-users mailing list > Mason-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mason-users ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
