On Monday 05 March 2007 16:19:14 Ian Bicking wrote: > Joseph Tate wrote: > > I find that multiple files gives you a nice way to override defaults. As > > long as the files are read in a way that's predictable and documentable, > > and ultimately appear as if read from a single file (and possible > > displayable via some diagnostics link in an application). > > Allowing this sort of thing means that the application carries around a > complete config object of some sort, which I rather dislike -- it allows > for smart applications, but it makes it much harder to understand the > configuration and any possible side effects. If we resolve the > configuration down to something more limited (as the Paste Deploy entry > points do) you can't really reconstruct the config from there. > *Something* could still reconstruct the config (an alternate config > loader, via logs, via debug settings, etc), just not the application > itself. > > This is somewhat problematic for applications that have particularly > complex config requirements, or want to support self-configuration. The > best solution that I can think of with Paste Deploy in that case is to > just use the Paste Deploy configuration to point to the "real" > configuration.
I agree. That's why my app has a /config link that spits out the "effective" configuration. The overridden config is a hard requirement, I'd love to hear alternative solutions. /etc/php.d, /etc/httpd/conf.d and that ilk come to mind as examples of this kind of thing. -- Joseph Tate Software Engineer rPath Inc. http://www.rpath.com/rbuilder/ (919) 851-3984 x2106 _______________________________________________ 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
