[Web-SIG] Config system

[Ian Bicking]

I've been doing some more work on a config file loader, part of WSGIKit: 
svn://colorstudy.com/trunk/WSGIKit

It's in wsgikit.config -- lazyloader in particular.

It has some features that I think are useful:

* Uses .ini syntax, i.e., easy to edit.  Doesn't use Python expressions, 
i.e., you don't need to quote all strings.

* Allows nested structures, in the form of dotted config keys.  Sections 
are just common prefixes for these keys.  I.e, these are equivalent:

   [vhost(my.host.com)]
   document_root = /var/www

and:

   vhost(my.host.com).document_root = /var/www

Parenthesis quote the values, so names aren't normalized inside 
parenthesis and .'s aren't interpreted.

* It saves information on where each configuration value comes from, so 
you don't have to check for validity up-front.  config.inischema was an 
experiment defining an up-front schema and requiring validity whent the 
config file was loaded.  This wouldn't work for WSGI, because we don't 
know what middleware is going to look at the configuration values up 
front.  But since it saves information, you can do validation at a late 
stage and still give error messages that give the filename and line 
number of the error.

* You can load several config files, each one overriding the previous 
ones, but with the previous values still visible if they weren't 
overrided.  This also works for nested dictionaries.  You can also get a 
list of all values for a key in all the config files (as well as the 
duplicated keys in a single config file).  Though in most cases I think 
it's best not to use duplicate keys, since key names can contain more 
information than in some systems (like Apache conf files).  E.g., 
"types.(text/plain).filter = myfilterapp", or "options.autoindexing = off".

* You can merge configuration values into new locations in a config 
file.  A common example would be virtual host configuration -- you can 
take a virtual host section and merge it into the main server section. 
You have to be careful about making the right copies, but the only thing 
that's destructively mutated is the list of shadowed dictionaries; so if 
two configurations share dictionaries it is safe.

* There's some possibility for writing config files out with changed 
values.  I haven't really thought it out completely, but it keeps enough 
information to make it possible.  The lazyiniparser module that 
lazyloader uses can write modules out with little information loss 
(mostly whitespace; comments are preserved and names aren't normalized). 
  With lazyloader it's a little more confusing, because it's not clear 
with the dictionary syntax which file would get the new or changed 
setting, or when it would get written.


It has a bunch of tests, though it's not exhaustive (using py.test; 
http://codespeak.net/py) and it has some docstrings.  There's nothing 
yet to actually integrate it with WSGI, and I'm probably going to first 
use it on a non-WSGI project.  But I think the integration should be 
fairly simple, just putting the objects in a known location in the WSGI 
environ.

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