[Web-SIG] Standardized configuration

[Ian Bicking]

>>  To do this, we use a ConfigParser-format config file named
>>  'myapplication.conf' that looks like this::
>>
>>    [application:sample1]
>>    config = sample1.conf
>>    factory = wsgiconfig.tests.sample_components.factory1
>>
>>    [application:sample2]
>>    config = sample2.conf
>>    factory = wsgiconfig.tests.sample_components.factory2
>>
>>    [pipeline]
>>    apps = sample1 sample2

On another tack, I think it's important we consider how 
setuptools/pkg_resources fits into this.  Specifically we should allow:

[application:sample1]
require = WSGIConfig
factory = ...

Since the factory might not be importable until require() is called. 
There's lots of other potential benefits to being able to get that 
information about requirements as well.

Another option is if, instead of a factory (or as an alternative 
alongside it) we make distributions publishable themselves, like:

[application:sample]
egg = MyAppSuite[filebrowser]

Which would require('MyAppSuite[filebrowser]'), and look in 
Paste.egg-info for a configuration file.  The [filebrowser] portion is 
pkg_resource's way of defining a feature, and I figure it can also 
identify a specific application if one package holds multiple 
applications.  However, that feature specification would be optional. 
What the configuration file in egg-info looks like, I don't know. 
Probably just like the original configuration file, except this time 
with a factory.

I don't like the configuration key "egg" though.  But eh, that's a detail.

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