[Zope-Coders] New API for Zope configuration info

[Tres Seaver]

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