[Zope-dev] Re: [Zope3-dev] ZConfig: a wish list

[Barry Warsaw]

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