[Zope-dev] Moving forward with Zope 2.7

[Chris McDonough]

On Tue, 2002-11-26 at 01:29, Jamie Heilman wrote:
> >     * where possible, the banishment of environment variables
> >       as configuration.
> 
> I have to say, I think this is a bad idea.  What is it about
> environment variables do you find worthy of banishment?  I can tell

"Banishment" was a bad word.  It's not really so much that I think that
environment variables are evil or anything, it's just that I think there
should be one and only place to find and set most configuration data for
Zope.

Currently you configure Zope via a combination of z2.py switches and
envvars.  There are currently 40 Zope environment variables and 22 z2.py
switches.  There is no definitive reason for any one of these settings
becoming a switch over an envvar or vice-vera (it was at the whim of the
particular developer who decided to add the config requirement), so it
appears (and is) rather haphazard.  Some things like 'Z_DEBUG_MODE" and
the -D switch actually even do the same thing, and it's hard to tell
which you're supposed to use and which is supposed to "win" in these
cases.  Additionally, some things aren't really configurable at all
(you're stuck with file or syslog logging, no way to send to an NT event
service, etc).  We'd like to fix this kind of thing and provide a more
consistent front-end to configuring Zope settings.

Additionally, since lots of Zope configuration data wants to be
hierarchical (loggers, zodb databases, severs), and since environment
variables and switches don't lend themselves particularly well to being
hierarchical, a  hierarchical config file format is nice.

I hope this makes sense as a defense of using a config file.  I don't
particularly like config files either, but I think once a piece of
software reaches a critical mass, they become a necessary evil.  In my
opinion, Zope reached that mass about three years ago. ;-)

> a) Code spent garnering values is minimal, I don't have to worry about
>    acres of code spent parsing yet another config file format or the
>    inevitable quirks and bugs in that code.  It doesn't get much simpler
>    than os.environ.get()

Yup.  We've got a seriously complicated piece of software to deal with
config files now, and it's only getting more complicated.  So I can
sympathize with this entirely.

> b) I have tools to examine runtime environments which are external to the
>    zope application and any of its limitations.  If I wanna know what
>    a particular value is, I can just find out using ps.  I don't have
>    to dig around in the zmi, or rely on any custom clients to query that
>    data from a running instance.

I feel that it's just as simple (or maybe simpler) to look in a config
file.  The Zope config file will be stored on the filesystem (not in the
ZODB), and it's in a format much like an Apache config file, so no ZMI
or custom client stuff will be necessary.  There will be tools provided
to parse the config file if necessary.

> c) Environment variables lend themselves to nicely to modification by
>    third party tools; I can set environment variables in shell
>    scripts, python scripts, whatever--the paradigm is language
>    agnostic.  In particular I'm rather fond of using daemontools and
>    its envdir program in conjunction with a custom z2.py replacement
>    that lets me take advtanage of the excelent supervision and logging
>    infrastucture provided by daemontools.  Force me to use an external
>    config file and its going to make this kind of thing more difficult
>    to do.
> 
> That said I know they aren't an end-all solution for all configuration
> needs, but just because they don't fit every need I don't see why they
> should be completely discounted.

They shouldn't be.  Lots of applications use environment variables as
"superglobals" (e.g. $HOME, $PYTHONPATH, etc.), and this should be the
kind of thing that Zope should use them for as well.  I can see, for
example, setting the SOFTWARE_HOME using an environment variable or
throwing some debug switch using an envvar.

But stuff like "ZSESSION_TIMEOUT_LIMIT" and
"ZOPE_DTML_REQUEST_AUTOQUOTE" and the mishmash of logging parameters
(STUPID_LOG_FILE, ZSYSLOG, ZSYSLOG_ACCESS, etc) are just begging to be
put into some sort of configuration file.

So far, we've done a bunch of work to come up with a config file format,
some parsing software, and some configuration schema software.  We're
hoping that with a little work, we can make the configuration of Zope
through a config file not suck *too* badly.

If you have ideas about what should (and should not) be done wrt
canonizing a config file for Zope, please detail specifics here as
nothing is set in stone.

Cheers,

- C