[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