[Zope-dev] Re: [Zope3-dev] ZConfig: a wish list
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 . > > 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: a wish list
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. PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: a wish list
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: > > > > > > > > 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: a wish list
[EMAIL PROTECTED] 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 >tag has a prefix attribute, import's package attribute > doesn't honor it, so there's a lot of duplication. For example: > > > > > ... +0 Well, 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 "" 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: > > > > 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. PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
