As I mentioned, I've been experimenting with Mailman 3 lately, using ZConfig as the configuration language for basic functionality. There are many things I like about ZConfig, but of course I have a few nits. Since the wiki Fred created on zope.org doesn't (or didn't) seem to work, I'll post my wish list here. Feel free to tell me why I don't really want what I think I want. :) - import honors prefixy In my schemas, I have a number of import statements, each with package and file attributes (since the default component.xml naming scheme doesn't work for my code layout). Unfortunately, if my <schema> tag has a prefix attribute, import's package attribute doesn't honor it, so there's a lot of duplication. For example: <schema prefix="mailman.config.components"> <import file="databases.xml"> <import file="domains.xml"> ... - $ 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. - default sections At some point I thought it might be nice to be able to define default sections, so that you wouldn't have to require something like "<defaultsect/>" in your config file. - Python command substitutions Something like: %define hostname socket.getfqdn() although I know there are some difficult issues with this (imports for one). - 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. That's it for now. -Barry
barry@zope.com writes:
Since the wiki Fred created on zope.org doesn't (or didn't) seem to work, I'll post my wish list here.
Good strategy. ;-) The wiki definately didn't work, and no one seems to know why.
Feel free to tell me why I don't really want what I think I want. :)
Rest assured, my life is based on telling you why you don't really want *that*!
- import honors prefixy
In my schemas, I have a number of import statements, each with package and file attributes (since the default component.xml naming scheme doesn't work for my code layout). Unfortunately, if my <schema> tag has a prefix attribute, import's package attribute doesn't honor it, so there's a lot of duplication. For example:
<schema prefix="mailman.config.components"> <import file="databases.xml"> <import file="domains.xml"> ...
+0 Well, <import package=".foo"/> doesn't honor the prefix, but that's not the same as what you describe above really (you're using the prefix instead of an omitted package). I agree that the package attribute should use the prefix; will fix. Regarding an omitted package attribute being replaced by the prefix, I think that's fine as long as there's a file attribute. No existing schema is affected.
- $ 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. 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 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.
- default sections
At some point I thought it might be nice to be able to define default sections, so that you wouldn't have to require something like "<defaultsect/>" in your config file.
+1 This is something Chris and I wanted from the beginning, but we never decided on the best way to approach it.
- Python command substitutions
Something like:
%define hostname socket.getfqdn()
although I know there are some difficult issues with this (imports for one).
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.
- 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'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. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
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
Barry Warsaw writes:
I suppose that model precludes even access to %define variables after parsing.
That's right. If you really want to control the structure of the pat specifications, you need to deal with it explicitly; create a setting to control the base directory, and then use os.path.join() to deal with paths relative to that base.
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.
Have your users complained that it's too much?
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.
I don't know enough about Mailman3 configuration to know how what's being done in the config file or how many decisions the site admin needs to deal with. Is there something for each list?
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.
This sounds very strange to me. Perhaps we should take a look at it when we're in the same town tomorrow. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Tue, 2003-12-30 at 13:48, Fred L. Drake, Jr. wrote:
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.
Have your users complained that it's too much?
Not yet, because there aren't any <wink>.
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.
I don't know enough about Mailman3 configuration to know how what's being done in the config file or how many decisions the site admin needs to deal with. Is there something for each list?
I'm hoping there won't. I'd like the ZConfig stuff to define only site-wide configuration stuff, like the ipaddress/port of your smtp servers, the http port and interface for the web server, etc. ZConfig might be used for list config defaults, but I'm not yet sure about that. -Barry
participants (3)
-
Barry Warsaw -
barry＠zope.com
-
Fred L. Drake, Jr.