[Zconfig] Overlaying multiple config files

[Moore, Paul]

From: Fred Drake [mailto:fred at zope.com]
> On Monday 26 April 2004 08:26 am, Moore, Paul wrote:
>> I have an application suite which currently uses ConfigParser for
>> configuration information. The config is built up in 3 parts, from
>> some hard-coded defaults, then from a suite-specific ini file
>> (suite.ini) and then from a further application-specific ini file
>> (app.ini). I'd like to do something similar with ZConfig, but I'm not
>> clear how to.

> This was never a requirement for ZConfig, so we've never implemented
> anything  like this.

That's a pity. It's messy in ConfigParser, but not too hard.

> It's not entirely clear what the right thing to do is in the 
> general case.  Given that the schema support is so different from 
> ConfigParser, I expect it would be difficult to determine the best
> way to merge two configurations.

I don't know about "best", but it seems to me that the practical
approach would be just to use values in a last-file-loaded-wins
order. Sure, this could result in 2 files which were individually
OK, resulting in an invalid "merged" configuration, but I'd say that's
just a case of "well, don't do that" :-)

As an alternative way of getting what I want, can sections of a config
file "override" each other? I'll give an example:

<database>
username general_user
password secret
connect my_db.my_server
</database>

<app1>
    <database>
    username app1_user
    password secret2
    </database>
</app1>

The idea being that any application can use config.database.username to
get at the username to use. But app1 can say (somehow) that it expects
the app1 section to override the information in the base section.

I know I can do

    try:
        username = config.app1.database.username
    except AttributeError:
        username = config.database.username

or some equivalent using introspection, but that's painfully tedious for
a large number of configuration items (and it makes the application code
far more tightly coupled to the schema than otherwise).

Paul.


__________________________________________________________________________
This e-mail and the documents attached are confidential and intended 
solely for the addressee; it may also be privileged. If you receive this 
e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group 
liability cannot be triggered for the message content. Although the 
sender endeavours to maintain a computer virus-free network, the sender 
does not warrant that this transmission is virus-free and will not be 
liable for any damages resulting from any virus transmitted.
__________________________________________________________________________