[Web-SIG] WSGI and Configuration

[Robert Brewer]

Ian Bicking wrote:
> Robert Brewer wrote:
> > Meh. I'm just speculating that specifying this within WSGI 
> could hurt
> > its adoption more than help. If we chose to force XML adoption, for
> > example, I'd be unhappy. But I'm willing to be convinced 
> otherwise. ;)
> > It'd be fabulous to standardize.
> 
> I'm not looking for any standard, I'd just like some feedback on 
> conventions.  As we start poking things into the WSGI environment, it 
> would be nice if we could agree on the API in there.  At some future 
> point, maybe it will seem reasonable to standardize that.
> 
> I'm not even worried about configuration files at this point, though 
> it's hard to ignore them entirely, as different file formats produce 
> different output (e.g., .ini is fairly flat, vs. something 
> like ZConfig or YAML which can be more structured).  Anyway, maybe
> we can support multiple formats, or let the server load the
configuration
> in whatever way it feels fit, or whatever.

Sorry; I misunderstood. I thought it had already been determined that
config data would go in environ['myapp.custom_data'] (or some other more
meaningful dotted-name), so I figured you were looking to change that.
Given that environ is already being passed in the standard through all
layers, I don't see any reason to change. Phillip's idea about passing
configs in a separate call seems like overkill to me--applications which
are bare functions (not classes) will have to grow a wrapper to receive
the configs, at the least. I think if we wrap one more callable in a
callable, my head's going to implode; WSGI is already more complex than
metaclasses ever were.

Every server is going to provide different mechanisms for specifying
single config options. If we stick to environ, they can provide that
pretty straightforwardly (and in a manner specific to their server, so
no convention is necessary).

> In regards to backward compatibility, I'm not too concerned 
> about that.

Nor am I.

> 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)."

> 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.
3. How to pass config data through a WSGI chain. In my mind, that's
already specified: environ.
4. How to load and normalize complex config data from various sources:
ini, xml, yaml, zconfig (heh, just noticed the "XYZ" acrostic ;).
5. How to minimize config file "spread" (?)

Which are you addressing? Or am I still missing it completely (wouldn't
be surprised)?


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org