[Web-SIG] windows, pywebd, webctl

Jim Fulton jim at zope.com
Fri Mar 9 14:52:38 CET 2007

On Mar 7, 2007, at 11:55 PM, Chad Whitacre wrote:

> All,
> Windows
> =======
> Sidnei, et al.: your points are well-taken and your expertise
> appreciated. Thanks!
> pywebd
> ======
> 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,
>      non-overlapping.

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
>      many-sites-on-one-server.

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:
>        etc/<foo>.conf
>        lib/python
>      Is there really a Unix sysadmin that would balk at this?


>     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 mailing list