ZConfig

The ZConfig Configuration Library

The ZConfig "home page" is available at http://www.zope.org/Members/fdrake/zconfig/.

Feature Requests

It might be nice to have some sort of conditional structure, perhaps similar to the cpp #ifdef / #ifndef stuff. This would be particluarly handy for having config files that sometimes include one another. You could avoid the problem of getting an error for trying to redefine a variable.
We need to be able to support values that take more than one line. Both continuation lines and text blocks would be best.
Here's a possible text block possibility: A text block type can be defined in the schema as a textblocktype (parallel to sectiontype). Instances of the type can be specified using textblock (parallel to key). The configuration syntax for the text block will be the same as that of a section, but the processing of the content will be different.

An example schema that defines a text block value might be:
```
         <schema>
           <textblocktype name="why"/>

           <textblock name="why" attribute="explanation">
             <default>
               (No explanation given.)
             </default>
           </textblock>
         </schema>
```
A corresponding configuration file that specifies a value for this might be:
```
         <why>
           This explains why the world is flat.

           You'd better sit down; there's a lot to this.
         </why>
```
The result of parsing the configuration file would be a configuration object that provides a single attribute, explanation. The value of the attribute would be a simple string.

The textblocktype schema element can specify a datatype attribute just like the sectiontype element; this can be used to enforce any special constraints.

Grrr.... Working on this, I find the ZConfig sources massively painful to figure out. The internal handling of information is very painful, and aspects aren't as carefully separated as they need to be. This is something that must be fixed, but I may have to shelve this feature for now (even though I could really use it in a current project). The revised ZConfig will include a document that explains the internals a bit more...
Input encoding support is needed to allow input of Unicode text values.
This could be done using either of
1. Recognize the Emacs convention for specifying the encoding. This has the advantages that a) Emacs recognizes it and b) Python is re-using is already, so we're not inventing anything new.
2. Using another "pre-processor style" marker such as %encoding. This isn't recognized by other software, but would fit nicely with the existing ZConfig syntax.
Simple enumerations should be possible entirely through the schema language instead of having to define a datatype in Python code.
Perhaps something like this in the schema:
```
         <schema>
           <enumeration name="group">
             <value>local</value>
             <value>remote</value>
             <value>virtual</value>
           </enumeration>

           <key name="preferred-group"
                datatype="group"
                default="local"
                />
         </schema>
```
In the configuration syntax, this could be used like this:
```
         preferred-group  virtual
```
The configuration object would have the attribute preferred_group with the string virtual as the value. The type registry associated with the schema would gain an entry for the group type; if the registry is shared, it would need to be replaced with a specialization containing types defined by the schema, using the original registry for existing type definitions.
Jim Fulton just realized that ZConfig is naturally case-senseless. The current behavior was mandated by our in-house sample users. I think us developer types would rather it be done differently; it's unlikely this can change substantially.
It is possible to set the keytype attribute for schemas and section types, which avoids most of the unwanted case sensitivity (but only if you do this consistently in your schemas and components), but this doesn't allow control of the names of sections, which are always converted to lower-case at a low level in the parser.

At one point, there was a nametype attribute that could be used to control this, but the implementation was discarded without being released as unnecessary. It would be nice to have it back, even without a correction to the default behavior.

Note: The zpkg tool uses a convoluted set of overrides and specializations to implement a case-sensitive world on top of the base ZConfig. It's way more tedious than it should be, but it works, and is isolated in a single module in the zpkgsetup package. This suggests that some refactoring would really help.
Jim Fulton wants to be able to pass ZConfig a flag to tell it to ignore unrecognized top-level sections. The intention is that additional sections could be added to the configuration file to support separate applications that share some configuration. This appears to be a short task, though it makes me queasy just thinking about configurations that can't be verified. It should be sufficient to only ignore unrecognized sections (and possibly keys) at the top level.
Note: ZConfig 2.5 includes a schemaless module that provides some basic ability to load, manipulate, and serialize a ZConfig-based configuration file without a schema, if the schema(s) that apply aren't too elaborate. This isn't exactly the same, but has been sufficient for use from zc.buildout recipes.

Features Added

When using the section or multisection schema elements, the name attribute should default to * ("don't care"), since name="*" doesn't actually provide any information. (Added in ZConfig 2.3.)
ZConfig provides a hook for loading resources from packages. This is necessary to support loading schema files from packages now that we're living with EGGs. The implementation is not specific to EGGs, but has been tested with a general ZIP file that zipimport can handle. (Added in ZConfig 2.5.)