Jim Fulton wrote: > > On Mar 2, 2007, at 8:17 PM, Ian Bicking wrote: > >> Jim Fulton wrote: >>> What have you used global configuration data for? >> >> It's often meant for configuration that applies to many components. >> For instance, a "debug" value that applies widely (or could also be >> applied locally). Or information about where to email errors, some >> logging information, etc. E.g., you might give a base directory for >> logging in global_conf, and an application could pick that up and >> probably put it in a subdirectory there (where if you configured it >> locally, you'd probably give the application the full path of the log >> file). > > I know what it's meant for. I was asking what it was actually *used* > for. Is this truly useful?
Well, for some things like the debug setting, definitely. That is, *some* applications consume that value, but not all, and in the form of global_conf the value just sort of hangs out without being applied to anything in particular. In deployments where I'm using a set of applications designed to work together I've found it useful to pass values to all of the applications at once. Also when you pass values in through the command-line it gets put into global_conf, because it's not clear what section it would otherwise apply to (since the application you are intending to effect may be wrapped by middleware). >> Also, it seems like there should be a better way to shut it down >> than killing the entire process. For instance, for performance testing. > > <shrug> This doesn't seem important to me. Really what I'd like it for is testing, in those times when I really want to start up a real HTTP server to test against, then cleanly shut it down. >>> Overall, PasteDeploy looks very usable. I'll probably find other >>> issues when I actually try to use it. One of my next projects wil be >>> to look at how to use it in Zope. zope.paste is a bit too much of a >>> wedge. >> >> zope.paste, as I remembered it, didn't really seem to allow things >> like instantiating multiple Zope applications. But I can't remember. >> And that's not always feasible; Zope 2 is unlikely to really support >> many truly separate instantiated applications, but it could still >> support the basic configuration. > > zope.paste tries very hard to minimize its impact on zope > configuration. It has to make a number of compromises to do this. It > is impossible to run "truly separate" Python applications in the same > process, for some definition of "truly separate" and "application". > separate WSGI applications will share common module definitions and > shared module globals. I can easily imagine separate Zope (2 & 3) > applications that exposed separate object spaces or sets of procedural > (as opposed to object-based) pages. "Separate" instances of applications is a fairly vague notion, that only means something when applied specifically. I would hope that you could start two Zope apps pointing at different ZODB instances, just like you should be able to start two apps pointing to different objects in the same ZODB. >>> On a related note, I'll probably want to do process configuration in >>> the same file that that PasteDeploy uses. This would likely include >>> things like: >>> - interrupt-check-interval >>> - Log files >>> I guess there is nothing to prevent this. I suspect that I'll also >>> get a lot of resistence to moving this out of zope.conf. :/ >> >> Yes, the container configuration. (Incidentally, what exactly do we >> call this thing we're proposing to make?) > > I'm not sure we're initially proposing to make *a* thing. For starters I > think we're exploring using the PasteDeploy-defined frameworks and to > collaborate on sever testing. > > I would call this the main program, but maybe other terms would be better. > >>> Have you tried pointing logging.fileConfig at a cnfig file containing >>> PasteDeplot sections? I assume it would work. >> >> I haven't tried it, but I think Ben Bangert has started work on that, >> using global_conf['__file__'] that way. A more cohesive logging story >> that included that would be nice. > > I think this should be done by the main program (container/whatever) not > by an application. In the case of Paste and Pylons, we wanted to add a bunch of logging to the library. The library at that point doesn't belong to any application. Having a bunch of logging without a clear story about how to use that logging seemed bad (in this case it's mostly logging intended for programmers, not final deployment, but some portions could be useful in final deployment). It could (and probably would) be applied as an outer middleware applied by individual applications, but ideally there would be shared conventions across frameworks. Ideally it would also make application-specific logging easier. I think logging configuration is a general use case we should consider, but I don't think it's part of the container really. It might relate to something in Paste Deploy configuration. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com