On Wed, Jan 20, 2010 at 7:54 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant <l.plant...@cantab.net> wrote: >> I don't understand how avoiding the settings.py mechanism will produce >> *more* flexibility. > > The problem -- at least as I see it -- is that of a intertwingulment > of "application" settings with "ops" settings. > > As organizations get larger, roles stratify more. Thus you end up with > a pretty big gulf between the ops team and the application developers. > In these environments, application developers probably shouldn't be > messing with things like the `DATABASE_*` settings -- in some > organizations its even a breach of policy for the developers to *know* > the database password! > > OTOH, ops types don't know what the heck to do with `INSTALLED_APPS`... > > And then there's middleware: some middleware (caching, etags) might > need to be controlled by ops; some by apps. > > Obviously you can *do* this with Django, and I'd argue it's not > particularly hard. Still, it's something that bigger orgs have to > figure out themselves.......
That's a problem that we have. We solve it very simply by splitting settings.py into a package and dividing these options. We also provide some machine wide configuration in /etc/ that won't get overwritten during update of the project - that's where ops guys store their passwords and everything. the mechanism is shortly described here: http://ella.github.com/tutorial/4-deployment.html#settings-py project template: http://github.com/ella/django-base-project/tree/master/djangobaseproject/ I think this can be solved by documenting different approaches (like http://code.djangoproject.com/wiki/SplitSettings ) or maybe even picking one and recommending that. Another problem that we have is error reporting. If your project blows up and starts generating hundreds of error messages per second, you really don't want then on your mailserver or mail client. It is also solvable with django's current tool set, but everybody must also figure it out on their own. We are currently working on some simple mechanism to handle this (offload the exceptions into a queue, group the same errors and store it in some DB or just log it), we will share the code as soon as it's finished.
-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
