[Web-SIG] Re: WSGI and Configuration

Phillip J. Eby pje at telecommunity.com
Sat Nov 13 19:30:10 CET 2004


At 09:52 AM 11/13/04 -0800, Robert Brewer wrote:
>Alan Kennedy wrote:
> > Well, I think that 99% of the time, configuration consists of just a
> > list of name/value pairs, although the value can obviously have
>complex
> > structure. Given that dynamically building data structures is where
> > python really shines, it should be possible to come up with something
> > flexible and powerful enough to cover the vast majority of situations.
>
>In my experience, that 99% can be served by:
>
>environ["myapp.config"] =
>     {'branch1': {'leaf1': 'value1',
>                  'leaf2': 'value2',},
>      'branch2': {'leafA': 'valueA'},
>     }

Which can also be rendered in flat form as:

myapp.config.branch1.leaf1 = value1
myapp.config.branch1.leaf2 = value2
myapp.config.branch1.leaf1 = value1
myapp.config.branch2.leafA = valueA

Which can be done with simple key=string configuration settings.

My current preference for the deployment standard is:

* Servers should allow you to specify an "application import" or a "setup 
import"
* Servers should allow you to specify a small number of short key/value 
configuration strings

An "import" is a combination of either PYTHONPATH+module or a Python 
filename, plus the name of an object to be obtained from that module or file.

An "application import" is an "import" that designates an actual WSGI 
application object (in which case the config data goes in its environ on 
each call).  A "setup import" is an "import" that designates a callable 
that should be invoked with a configuration mapping, to obtain the 
application object.  It could be used like this:

def setup_my_app(options):
     return MyAppClass(**options)

or this:

def setup_my_app(options):
     return app_from_file(options['CONFIG_FILE'])

or this:

class Application:

     def __init__(self,options):
         self.load_config(options['CONFIG_FILE'])
         # etc.

     def __call__(self,environ,start_response):
         # app code here


I would suggest that the configuration mapping should include WSGI-specific 
configuration variables like the multithread/multiprocess/run-once flags, 
and also any CGI variables that will be constant over the application's 
lifetime, such as SERVER_NAME, DOCUMENT_ROOT, etc.






More information about the Web-SIG mailing list