[Web-SIG] [Proposal] "website" and first-level conf (was: more comments on Paste Deploy)

Jim Fulton jim at zope.com
Mon Mar 5 12:59:09 CET 2007


On Mar 3, 2007, at 11:27 PM, Chad Whitacre wrote:
...
> Now, Jim: it looks like Zope still uses a Unix-y userland for
> INSTANCE_HOME, yes?

Yes, but I hate it.  At Zope Corporation, We're moving away from it  
for a number of reasons.

For development, it adds structure that isn't needed.  A Zope  
instance really only needs a few files.  Trying to minic some  
notional unix layout just adds pointless structure.

The traditional complex Zope instance file layout lead to the use of  
an instance "skeleton" to deal with all of the files, which led, in  
turn, to a copy and hack style of configuration customization that is  
inflexible and encourages cruft.

For production deployments, we (Zope Corporation) install files into  
the *real* Unix tree where site administrators want them.  We'll  
typically have a deployment that includes a number of applications.   
The deployment will create directories in /etc, /var/log, and /var/ 
run, where the applications in the deployment put their  
configuration, log, and run-time files.  They may also put files in  
places like /etc/init.d, and /etc/cron.d.  The point being that this  
looks nothing like a traditional Zope instance installation.

Keeping the number of files used by an application minimal makes it  
easier deal with the different needs of development and deployment  
and makes it easier, at least for me, to deal with different  
configurations.

...

>   1) Server benchmarks and inter-op standards (Jim)

Ian said he would lead this.

2) Common framework for WSGI application composition.

>   2) Common process management library (Bob)
>   3) Common web app server

Not sure what this is.

>
> Without discouraging the first two efforts, I'd like to champion the
> third. Here would be my proposal:
>
> First, we define a "website" on the filesystem as a Unix-y userland
> with, at minimum, the following:
>
>   etc/<foo>.conf
>   lib/python

-1 for reasons I've already described

I'll note that I find lib/python especially silly.  Why have a lib  
directory that contains a single subdirectory.  We started this a  
long long time ago with Zope because that's how Python installed it's  
own modules on Unix systems at the time. Since then. Python has  
switched to lib/pythonV.V.  We don't mimic that for hysterical  
reasons.  If someone really wanted to mimic how modules got installed  
into modern Unix Python installs, they'd use lib/pythonV.V/site- 
packages, which would be the height of absurdity.

In practice, at least for us at Zope Corporation, our process  
instances don't have any Python modules.  We have application  
definitions that contain the modules we use and multiple process  
instances of each application that contain only configuration data.

> Second, we adopt a simple ini-style format for <foo>.conf, which
> handles low-level process config. This file would then point to a
> second, framework-specific configuration layer.

We do something like this now.  It don't require any particular file- 
system layout.

The devil is in the details.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org





More information about the Web-SIG mailing list