On Mon, 2003-12-29 at 15:07, Fred L. Drake, Jr. wrote:
- $ substitutions in defaults
Often, my defaults for keys can be expressed in terms of $ substitutions that are more general for my system. Unfortunately, there doesn't seem to be any way to make this work. ZConfig itself doesn't perform $ substitutions on default values, and there doesn't appear to be a way to get at %define variables from Python.
-1
This would mean that a schema could require that certain %define names be provided by a configuration. It's certainly possible to make changes to ZConfig to support this, but they'd be fairly substantial.
The current model makes the %define and $-substitution a syntactic detail of the configuration language.
I suppose that model precludes even access to %define variables after parsing.
One of the chief motivations for this is to allow some directory to be specified as the "home" for other directories to be specified relative to. For example, log files might be specified relative to a log directory or an "instance home" directory. My usual response has been that it can already be done reasonably using something like:
%define topdir /some/path/to/the/top/of/my/tree %define logdir $topdir/log
some-logfile $logdir/interesting.log other-logfile $logdir/another.log
Which is essentially what I do now.
Another possibility is to perform os.path.join() operations using the "base" and "relative" portions in the application. This is less than ideal, but quite workable.
Still another possibility is that a new "relative-directory" type be implemented and some way to say relative-to-what (where "what" is some other setting, possibly at an outer layer in the configuration hierarchy). References to outer layers of the hierarchy makes this tedious to implement at best.
Given that it's not clear that this is needed, the additional complexity seems excessive.
If you have a (real) use case not related to specifying absolute directories, or for which the $-substitution approach isn't viable, please tell us about it.
That's the primary motivation, for sure. The idea is that if ZConfig is going to be the configuration language that Mailman3 site admins use, I'd like to reduce to a minimum the number of options or lines of files they need to look at, decide about, and change. If they can simply define a basedir and have all the defaults be defined in terms of that, it would be a bonus.
Do you really want this, or would some way to pre-define %define names be sufficient? This feels slightly less nasty than requiring %define from the schema. It would require opening up the API a little more, though.
Pre-defining %define names might be sufficient.
- attributes default to type
When defining a section, if I don't provide a section name, it would be nice if the attribute was defaulted to the section type. E.g. in this example:
<section type="databases" name="*" required="yes" attribute="databases"/>
IWBNI I didn't have to duplicate the "databases" string.
-0
This seems like a really minor bit of syntactic sugar. It would be easy to implement, but doesn't seem like it really buys much.
I'm not sure it's useful, but the style of the schemas I've been writing make all that extra stuff kind of redundant. I actually depend on the type and attribute names being the same because of the way I dig values out when I post-process stuff in Python.
I'd be more interested in making name optional, defaulting to "*", if attribute is specified. That's about the same amount of sugar, and seems more useful to me.
anything-to-cut-down-on-the-boilerplate-ly y'rs, -Barry