[PEAK] Unifying configuration

[Phillip J. Eby]

At 08:47 PM 12/19/03 +0200, alexander smishlajev wrote:

>>What I'm wondering about is whether this would be too brain-boggling of a 
>>syntax.  So far, .ini files have a comforting regularity to their 
>>format.  So, if you wander through and see something like this in the 
>>middle, what would you think?
>
>with all the complexity of current peak.ini file contents, i do not think 
>that these syntax variations will be a big problem.

But currently, all the contents consist of [sections] with 'setting=value' 
lines.


>>So one more possible approach:
>>[Special section of some kind for something blah...]
>>foo.bar =
>>     %import my.package
>>     <SomethingFromMyPackage>
>>     SomeSetting spammity spam
>>     </SomethingFromMyPackage>
>>That is, in certain special sections, you can use ZConfig nested within a 
>>setting, without needing any quotes.  (Naturally, such sections would be 
>>using *only* ZConfig for settings; pure Python would not be an option in 
>>such sections.)
>
>this one is good, also.
>
>but (as far as i understood) the first approach is more flexible, allowing 
>different section handlers, not only ZConfig syntax.  so i would prefer 
>the first one.

Different section handlers are already allowed, so long as they follow the 
'setting=value' pattern.  The 'value' need not be a Python expression, even 
though most existing section handlers are.

Section handlers are currently registered in the 
[peak.config.iniFile.sectionParsers] namespace.  (See the start of peak.ini 
for where the built-in ones are registered.)  Parsers named there have to 
implement 'config.ISettingParser'.

In fact, I'm about to add a new section handler, "[Import on Demand]", 
which will allow you to define shortcut names so you don't need to use 
importString or importObject in .ini files if you don't want to.  It'll 
work like this:

[Import on Demand]
module1 = "some.package.module1"
module2 = "other.package.module2"

[some.other.section]
something = module1.SomeClass(someParam=module2.OtherClass())

To speak precisely, each name=value setting in an [Import on Demand] 
section will be equivalent to executing 'name = lazyModule(value)' in the 
globals dictionary used to evaluate expressions defined in the 
configuration file.  A configuration file will inherit globals defined by 
the files that include it, but not the other way around.  Note that this 
means you can't put frequently-used imports into an include file, but the 
flip side is that there's no way for a file to have its globals altered by 
another file.  So, if you define a name in the file, you know you're 
getting *that* definition, and no other.  If you don't define a name, what 
you get depends on where the file was included.

With this addition, a lot of the need for using ZConfig syntax in .inis 
will go away, since you'll be able to very cleanly create even complex 
objects in an expression.  This will be available for *all* expressions 
evaluated in .ini files, not just special ZConfig-formatted sections or 
settings, so it's more generally useful and doesn't require a schema to be 
set up.

To handle the other issues we were trying to solve, I think we're going to 
also need a mechanism to access the "previous definition" of configuration 
rules, so that definitions of various sorts can be chained 
together.  Alternatively, a mechanism to allow iteration over values in a 
given namespace.  But I haven't worked out the details of either concept 
yet.  Both will probably require some "interesting" refactorings of parts 
of the configuration package, though.