[Zope-Coders] New API for Zope configuration info

[Chris McDonough]

Backwards compatbility aside, I am -0 on supporting envvars at all going
forward.  Here's why:

  - I'm not sure it's any easier for a developer to set envvars
    than it is to cook up a small script with the respective
    command-line equivalents.  

  - It's a lot easier to forget that envvars are set, making it
    possible to chase your tail when dealing with multiple Zope
    instances from the same shell
(STUPID_LOG_FILE=/some/file/you/dont/really/want/to/write/to/from/every/zope/on/your/system
    as an example).

   - the zopectl shell allows developers to pass command-line args to
     the "start" verb, and allows for "execute the last command by going
     up and pressing enter" via readline, so this could be used when
     repeatedly stopping and starting a particular Zope instance as
     opposed to using envvars to "remember" instance-specific settings
     during development. 

   - envvars are just yet another thing we'll need to maintain
     documentation for, and we clearly suck at maintaining
     documentation.

As far as backwards compatibility goes, envvars are (somewhat
unfortunately) "the tip of the iceberg".  It would be slightly
disingenuous of us to provide envvar support for b/c reasons when all of
the rest of the supporting install/startup machinery has changed (no
"z2.py", no "start" script, no "wo_pcgi.py", etc.).  With the changes in
the pipe, we're either going to need to create a "compatibility layer"
that makes 2.7 install/startup look a lot like previous 2.X
incarnations, or folks will need to cope with the differences as best
they can.  That said, the new install and startup scheme is much better
than the old (I suspect it will actually make sense to most people ;-)

I am hoping that Fred will volunteer to create and post to zope@ or
zope-dev@ a more genereal summary of the install/startup changes implied
by 2.7 so we can get a sense of what kinds of "real-world" impacts that
the changes will have.

- C

On Tue, 2003-02-11 at 23:32, Tres Seaver wrote:
> On Tue, 2003-02-11 at 17:06, Fred L. Drake, Jr. wrote:
> > 
> > Andreas asked:
> >  > What about backward compatibility (for all exisiting env vars?).
> > 
> > and I responded:
> >  > We somewhat torn about how to deal with environment variables.  One
> >  > proposal has been to select the value of a field from the following
> >  > list of sources.  Sources earlier in the list override later sources:
> >  > 
> >  >   1. command line
> >  >   2. configuration file
> >  >   3. environment
> >  >   4. intrinsic default
> > 
> > Well, I indicated I wasn't sure I liked this arrangement.  I'm going
> > to propose that we use a different ordering instead:
> > 
> >   1. command line
> >   2. environment
> >   3. configuration file
> >   4. intrinsic default
> > 
> > I think this makes more sense, because it reflects both the difficulty
> > of changing values at each "layer", and the relative permanence of
> > each layer.
> > 
> > This also makes it easier to implement (lower risk), as I'll only need
> > to extend the option support in the zdaemon.zdoptions.ZDOptions class.
> > 
> > Part of the motivation for this is that the values that ZConfig
> > returns may have been provided by either a configuration file or the
> > configuration schema; introducing another layer at that point would
> > actually be more tedious than changes to ZDOptions to support
> > environment variables.
> 
> Hmm, this is actually closer to what I was thinking originally;  I
> punted on it because of Chris' known sentiment against allowing the
> environment to get "in the way".  I think we have two distinct use
> cases:
> 
>   - Sysadmins need a high level of predicatbility in how the server
>     runs.  For them, environment variables are likely a pain, as they
>     transfer essential configuration information to the startup script
>     (bad) or to the login profile of the user running the server
>     (much worse!).  I believe that this use case is the primary
>     motivation for Chris' desire to avoid environment variables, and
>     instead use only configuration from the file.
> 
>     Note that command line options are also a no-no for "production
>     stable" use for the same reason:  they transfer configuration
>     to the startup script.
> 
>   - Devlopers need to be able to start and stop the server repeatedly,
>     varying the configuration in order to test it, or to test the
>     server.  Command-line options exist to make the developers happy,
>     and environment variables are essentially a "memo-ized" command
>     line option for them (avoiding the need to re-type the "common"
>     default).  Being able to override the configuration file *without
>     modifying it* is important to those who may have to maintain a
>     server on a system where they are not allowed to write to the
>     '/etc' (or whatever) directory.
> 
> For the second case, perhaps we could require that a single command
> line option would be required to enable the "environment overrides
> config file" layer, much like the '-e' flag in classic 'make'.  That
> one option wouldn't be too much hassle to type, but would make the
> production case "fail-safe" (at least, predictable by default).
> 
> Tres.
> -- 
> ===============================================================
> Tres Seaver                                tseaver@zope.com
> Zope Corporation      "Zope Dealers"       http://www.zope.com
>