[Web-SIG] WSGI deployment config

[James Gardner]

Hi All,

Have there been any more developments off-list about the format of the 
config file for WSGI deployment?

I'd like to apply the entry points labeling idea to sections in the 
pipeline config file and propose the following extensions to the format. 
Here is an example to start with:

[database: connection from database == 0.6.0]
host = 'mysqldb.pythonweb.org'
user = 'foo'
password = 'bar'

[connection from database == 0.6.0]
extra-non-standard-params = 'params'

[application: testApplication from web == 0.6.0]
message = 'Hello World!'


Each section represents the configuration of one piece of middleware as 
before. Standard configuration sections are labeled and non-standard 
extensions to standard sections use the same deployment string but with 
no label so in the example extra-non-standard-params = 'params' is 
considered a non-standard extension to database configuration.

This has three advantages:

1. Standardisation between similar WSGI middleware components becomes 
easier because we could all agree to name standard database connection 
parameters as database so middleware can be more interoperable. 
Non-standard extensions can be named in a similar config section but 
without the database label so that we define an extensible base standard.

2. Configuration can be accessed in code by name eg 
config.get('database') or config.getAll('database') to get custom 
extensions too. This means that whatever version of a package you are 
using you can still refer to the correct configuration easily and also 
use the configuration file in external scripts eg. to setup necessary 
database tables etc without creating the full middleware chain.

3. It allows us to create a configuration hierarchy. I've written a WSGI 
framework named Bricks http://www.pythonweb.org/bricks/ and the way it 
works is to have a global config file for all applications at a site and 
then a local config file if the application needs to override global 
settings or provide extra middleware. The logic behind this is that 
things like database connections are likely to be used by all 
applications across a site and a new application you have installed from 
a third party is not going to have the correct database settings so you 
would want to use the settings defined in the global config file. Using 
the new config file format we could simply say that if a global 
configuration does not already have a named config section which appears 
in a local config file then the local configuration is added below the 
last piece of global configuration that matched (or at the end if no 
matches were found).

We can also define an extension to this basic format: always include and 
always exclude determined by a + or - sign just before the entry point 
name so that we can also override global settings in a local config file 
and provide a flexible configuration chain of as many config files as we 
liked.

Here is an example to illustrate. We have an application which doesn't 
need authorisation middleware but does need a session store. It needs a 
database connection but is only capable of interacting with the one it 
specifies, it also needs some configuration of its own. It is installed 
on a site with other applications which use database, session and auth 
middleware. The site administrator wants all applications to use GZip 
encoded output.

global.wsgi:

[gzip: gzip from compression==0.1.0]

[database: connection from database== 0.6.0]
adapter = 'mysql'
database = 'test'
user = 'foo'
password = 'bar'

[auth: auth from database==0.6.0]
extra-non-standard-params = 'params'

[session: session from web==0.6.0]
params = 'interesting'

local.wsgi:

# Override any other database definitions
[+database: connection from database==0.6.0]
adapter = 'engine'
database = 'default'

# Define a session configuration to be use if no other is available
[session: session from web==0.6.0]
params = 'default'

[application: appSettings from app==0.1.0]
name = 'foo'

# The user installing the application wants to specifically
# exclude auth middleware since they know it isn't needed
[-auth]

If the global configuration file wasn't present, the application 
configuration would look like this:

[database: connection from database==0.6.0]
adapter = 'engine'
database = 'default'

[session: session from web==0.6.0]
params = 'default'

[application: appSettings from app==0.1.0]
name = 'foo'

But when it is installed on a site with the global config file it looks 
like this:

[gzip: gzip from compression==0.1.0]

[database: connection from database==0.6.0]
adapter = 'engine'
database = 'default'

[session: session from web==0.6.0]
params = 'interesting'

[application: appSettings from app==0.1.0]
name = 'foo'

So as you can see this allows a flexible deployment heirachy. What do 
you think?

On a broader point I'd like to see pipeline configuration (what we are 
talking about here) quite separate from the actual deployment details 
such as where the application is going to be installed on a URL. I don't 
think there is any need to standardise the latter as long as all 
frameworks are capable of using the basic pipeline and deploying it in a 
way they see fit, otherwise you start making the main application 
configuration too framework-specific.

James