[Web-SIG] windows, pywebd, webctl

Brian Sutherland jinty at web.de
Mon Mar 12 06:41:43 CET 2007


On Fri, Mar 09, 2007 at 01:22:58PM -0500, Chad Whitacre wrote:
> That's fair enough. So what if a proposed common executable acted 
> like this:
> 
>    1. A configuration file may be specified on the command line.

+lots

>    2. If no config file is named on the command line, then look
>       for one in certain locations:
> 
>         /etc/<foo>.conf
>         /usr/local/etc/<foo>.conf
>         ~/etc/<foo>.conf
>         ./etc/<foo>.conf

Perhaps you might want to think about /etc/<foo>/<foo>.conf, because
applications generally grow config files. In this case the second-layer
config.

Postgresql even does:

/etc/postgresql/${version}/${instance_name}/

So you can have many instances of many versions running at once. That
makes upgrading much easier.

>    3. <foo>.conf does basic process config (address, user/group,
>       threads, etc.) and hands off to a second-layer config (be it
>       paste.ini, zope.conf, etc.)

Perhaps specify the second-layer config file location in the first layer
config.

>    4. The following are added to PYTHONPATH *if they exist*:
> 
>         ./lib/python2.x
>         ./lib/python2.x/site-packages
>         ./lib/python
>         ./lib/python/site-packages

-1

Why not just write additional PYTHONPATH locations into the script when
you create it? The thing that creates the executable should know where
its putting the libraries.

> Such an executable would satisfy me. Would it be flexible enough 
> to meet your requirements?
> 
> 
> 
> 
> chad
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/jinty%40web.de
> 

-- 
Brian Sutherland


More information about the Web-SIG mailing list