On Thu, Jan 21, 2010 at 2:54 AM, 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.
I'm in full agreement that this is a problem. However, isn't the solution just a matter of adequately documenting the options that are already available? We could certainly improve the documentation for complex deployments - e.g., pointing out that: * settings.py can import base_settings.py * DJANGO_SETTINGS_MODULE lets you call your settings.py whatever you want * documenting which settings are operations, and which are application I'm not convinced that we have anything particularly technical to address here. > 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. It strikes me that this is just one example of a whole class of "best practice" stuff that we should document, but don't at present - like project layout, automated deployment, continuous integration, configuration management, etc. We've historically avoided having documentation on how to use Django with external tools (except when we have to, as in the case of mod_wsgi). A big part of the solution to the problem you've described is to establish a vetted best practice, and documenting that practice on our website as a community resource. The rest of the solution falls to the toolchain outside of Django itself. It still needs to be solved, but it isn't a Django problem specifically. One option here might be to take the Apache model, and use the DSF to incubate tools that have benefits to Django. However, that's part of a much bigger discussion. Yours, Russ Magee %-)
-- 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.
