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

[Fred L. Drake, Jr.]

barry at 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