>     * 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
you a few of the reason I really like them:

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()

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.

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.

Jamie Heilman                   http://audible.transient.net/~jamie/
"You came all this way, without saying squat, and now you're trying
 to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile?
 I liked you better when you weren't saying squat kid." -Buddy

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to