[Web-SIG] WSGI and Configuration

[Ian Bicking]

Robert Brewer wrote:
>>Rather I would hope frameworks in the future will use this 
>>convention, at least as an option.  E.g., they could use an
>>environmental variable, native configuration files, etc.,
>>but if they see configuration values in some agreed-upon
>>location in the WSGI environ they'd use those as 
>>well (maybe with precedence, or maybe as a fallback).
> 
> 
> I don't see any problem with the PEP as it stands (the "Application
> Configuration" section). Middleware and apps can read the environ
> variables they care about. As the PEP says:
> 
> "But, most existing applications and frameworks will probably only need
> a single configuration value from environ, to indicate the location of
> their application or framework-specific configuration file(s)."

I'm not proposing this effect the WSGI PEP at all, or hold it up at all. 
  (BTW, Phillip: is there anything keeping it from going final just like 
it is?)

>>This way at least the user has a chance of keeping their 
>>configuration files under control.  If they are already
>>scattered about, then they can probably stay that way.
> 
> 
> So you want them all in the same folder or file? I can't figure out
> exactly what concrete behavior you're trying to promote (or avoid). I'm
> getting lost in the rabbit holes. It seems to me there are at least five
> separate issues here:
> 
> 1. How a given server populates wsgi environ dicts.
> 2. Dynamic imports from dotted package names. A minor issue, but
> recurring.

This is quite separate.

> 3. How to pass config data through a WSGI chain. In my mind, that's
> already specified: environ.

Either we put them as a normal environmental variable (e.g., 
environ['APP_INSTANCE_HOME']), or the are more structured and go in some 
other variable.  I'd like the more structured approach, as the 
configuration can only be extremely minimal otherwise (i.e., point to 
configuration files).

> 4. How to load and normalize complex config data from various sources:
> ini, xml, yaml, zconfig (heh, just noticed the "XYZ" acrostic ;).

That's a separate concern I'm not too worried about.

> 5. How to minimize config file "spread" (?)

This is what I'm thinking about (and it relates some to 1).  If I have 
an application that uses several separate components, I want the 
application to have a single configuration file.  And it's always nice 
if you can give some of those values on the command line, which is where 
the server may come in.

Of course, I could probably fake it given a frontend script written 
specifically with those components in mind.  That would call for zero 
configuration on the part of the components -- rather everything is 
specified explicitly during construction (i.e., keyword arguments).  And 
maybe that's okay...?

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org