[Web-SIG] ConfigParser for configuration

[Fred Drake]

On 3/9/07, Chris Withers <chris at simplistix.co.uk> wrote:
> You have free reign now, right? ;-)

Heh.  Compatibility is worth something, even to me.

> You mean like the format expected by logging.config.fileConfig?

I haven't looked at that in a long time, but I think that's right.
Essentially, each user of configuration data has to know which
portions of their own configuration contains references to other
sections, and then chase those down (or pass them along) to use that
information.  This would take the form of "foramatter =
verbose_formatter" and the [verbose_formatter] would have all the
configuration data for the formatter.

> > It doesn't take care of things magically without some
> > additional help, for which we've avoided premature abstraction.
>
> Not sure what this means...

The application itself has to understand that it's creating an
arbitrarily nested structure from a simple (two-level) hierarchy.  How
that happens is part of the application, not a magical helper library.

> Okay, so, say I have a config.ini and I want to have logging sections
> for using in logging.config.fileConfig and other sections for use by my
> app's config.
>
> How would I share the one config file between fileConfig and whatever my
> app uses to tickle ConfigParser? Would each section have to parse the
> file? Would the get confused about keys not designed for them?

If you really want to use logging.config.fileConfig(), I'd suggest
your app having something like "logging-configuration =
/path/to/logging/config.ini", and using that to call the logging
configuration with the indicated file.

> Can one config.ini include other .ini files in the same way ZConfig allows?

No.

> What is this support for layering multiple files? I couldn't find it
> anywhere in the ConfigParser docs :-S

What this needs to be depends on the application.  There's a simple
layering included in ConfigParser (call read() with multiple
filenames, or readfp() more than once), but that doesn't serve
zc.buildout well.  You can look in the zc.buildout documentation and
code for what that does; look for "extends".


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca