[Web-SIG] WSGI and Configuration
Phillip J. Eby
pje at telecommunity.com
Sat Nov 13 00:42:09 CET 2004
At 05:03 PM 11/12/04 -0600, Ian Bicking wrote:
>Has anyone thought about what configuration might look like in a WSGI
>context? I'd like to set up some interface where configuration can be
>shared between frameworks. It's also important to me that configuration
>can be local in some fashion, not process- or installation-wide. For
>instance, override some configuration values for a specific URL hierarchy.
I don't know if this is what you're talking about, but the most basic form
of configuration that every WSGI server/gateway *should* support is simple
key-value pairs in 'environ'. For example, a Zope X3 WSGI application
might want a 'ZOPE_SITE_CONFIG' environ variable to tell it where its
configuration file is. In the simplest case for monolithic servers, this
can be set as an OS-level environment variable. For more complex servers,
this can be server configuration-driven. (E.g. Apache configuration files
can set environment variables per path.)
So, the simplest approach for apps is to receive this sort of per-instance
deployment configuration is via an 'environ' variable, and server/gateway
implementers are urged to allow per-instance settings of these variables.
>Maybe the most obvious way would be something like environ['config.dict'],
>which would be a two-level dictionary (sections and keys), reminiscent of
>a .ini file. It might not be an actual dictionary, to more easily allow
>configurations to be layered and unlayered.
>But that's not very sophisticated, so I'm curious if anyone has any thoughts?
Heh. It's more sophisticated than what I'm suggesting, but I think maybe
we have different use cases here. I'm seeking to support the diverse
existing configuration formats that applications and frameworks "in the
wild" already have, in a way that leans towards putting that configuration
in the server setup, while minimizing the scripting needed for deployment.
Actually, I think there are now starting to be enough deployment examples
to maybe add a "Deployment Recommendations" section to the PEP. It seems
to me that the best practice at this point is:
* Application developer should supply their application as an importable
object, and specify what configuration variables it requires.
* Servers/gateways should support specifying either a source file+name, or
module+name, to obtain the application
* Servers/gateways should support specifying name+value string pairs to
configure the aforementioned application. Each application instance should
be able to have its own configuration, even if the actual application
callable is the same object.
Alternatively, I wonder if perhaps there should be an "application setup"
importable, that gets passed the configuration, and returns the
application? This would be useful for applications that want to do some
initial setup, and don't want to have to write a bunch of code to manage
More information about the Web-SIG