[Web-SIG] windows, pywebd, webctl
jim at zope.com
Fri Mar 9 14:52:38 CET 2007
On Mar 7, 2007, at 11:55 PM, Chad Whitacre wrote:
> Sidnei, et al.: your points are well-taken and your expertise
> appreciated. Thanks!
> Bob: I'm on board with your vision for a common server library
> here. Count me in.
> webctl/filesystem layout/config syntax
> This is looking less hopeful as a place to collaborate:
> - An executable needs a config file on the command line, and/or
> a config file in a pre-determined place.
> - *Requiring* a config file on the command line is butt-ugly.
> - Our opinions regarding filesystem layout seem to be, um,
You are missing another alternative. First, keep in mind that with
setuptools, "executables" are just wrapper scripts that:
- Set up sys.path
- Import an entry point, and
- Call the entry point
These wrapper scripts are *automatically generated*!
It is just as easy to generate wrapper scripts that pass the name of
a configuration file to the entry point along with other arguments.
This is in fact what we're doing. This means that the script joins
the software configuration (represented by the entry point and eggs
used) and the process configuration, represented by the configuration
file. I'm very happy with how this is working for us.
(If you're interested in the gory details, see:
In particular, to see an example of the sort of generated script I'm
talking about, go to:
and scroll up.)
> I'd like to venture one more round on this, however, before
> giving up on it:
> - It might be the case that Zope only has a few files in an
> INSTANCE_HOME, but I find myself putting quite a bit in a
> site's userland:
> - I'll install Python packages in there wholesale, so I get
> their scripts in bin/, and lots of modules in lib/python.
Many Zope users put Python packages in their instance homes. I
mentioned this in another note as a justification for a
subdirectory. Personally, since all of the deployments I do are
large and require multiple instances of the *same* application, I
prefer to create a separate application installation and than create
multiple instances of that. Most Zope users don't seem to need this
however combine process instances and application instances into the
single concept of Zope instance.
> - I have multiple configuration files in etc/ (as
> discussed) along with templates in etc/templates/.
We generally take the view that templates are part of the software
and are managed in Python packages.
> Keeping it all in svn means that a website is very nearly
> self-contained and isolated, requiring not much besides
> Python to be installed in the base system. This is great for
Absolutely. We, of course, check everything into svn. We (ZC) use
buildouts to assemble the parts we need, which are typically shared
across many projects.
> - For one-site-on-many-servers, why does a Unix-y userland for
> development conflict with deployment?
> That is, why can't a
> development userland simply be installed into /usr/local for
> deployment? Surely logging differences could be handled in
> configuration, no?
Because site administrators who actually run the servers and who get
woken up in the middle of the night when something goes wrong want
application files to be in standard places, like /etc, /var/log, and
so on. These people are not developers. They are not well served by
"self-contained" applications, which are, for them at least, only
part of a much bigger system configuration.
Also note that on multi-core multi-process servers, we have many
instances of the same application on the same server, so what
normally gets put in a traditional zope instance is split between an
application definition and multiple process definitions. In
deployment, we install the application definition as an RPM. We then
use tools provided by the application definition to create instance
configurations based on the particular machine's configuration. (For
ZC, the machine configuration happens to come from a centralized
> - Besides, my proposal only specified two requirements:
> Is there really a Unix sysadmin that would balk at this?
> is all that's really needed for a common executable to get
> your site online. Lay out the rest however you want.
But you don't actually need this at all.
> - Jim, you hold particular distain for lib/python, but it's
> probably the best example of my "standards enable tools to
> evolve" argument: lib/python buys you distutils, setuptools,
> easy_install, workingenv, etc.
No, actually it doesn't. It is based on an out of date convention.
workingenv doesn't use it. It uses lib/pythonx.x. Distutils doesn't
really use it unless you confider the --home option (or whatever
it's called). Distutls is happy to install almost anywhere using --
install-lib. easy_install wants to install into your system Python.
lib/python is no easier to supply as an alternate install location
than any other. lib/python violates "flat is better than nested" by
introducing a pointless lib directory.
> - This same principle makes sense of runzope, scriptzope, and
> debugzope: standardize the file format (= fs layout), and
> such tools fit perfectly in /usr/local/bin.
Except that this isn't appropriate for deployment. When you need to
do something different, system that assume things about file-system
layout produce gordian knots. I speak from experience from work on
bending zope installations to the will of the people with the beepers.
> - Almost all of the Windows discussion has centered on daemons
> vs. services. Sidnei, et al.: what does a "native" Windows
> filesystem layout look like for a web application? Is using a
> self-contained Unix-inspired layout faux pas?
> - As mentioned wrt PHP, users like familiar filesystem layouts.
> Reaching agreement here improves our story for newcomers.
I don't have a problem with people using whatever layout they want.
I don't even object to having common layouts that are documented and
taught. What I can't accept is a software framework that *requires*
a particular layout to function.
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