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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
