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, and that can be a barrier to adoption. The enterprisey world solves this with standards like WAR and servers like Glassfish: if I'm an application developer, all I need to do to deploy is somehow produce a WAR. And if I'm a ops person, I just take that WAR and slap it into Glassfish. It's rarely that easy in practice, of course, but the execs making the tech decisions don't know that. Jacob
-- 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.
