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