On Fri, Jun 4, 2010 at 3:30 PM, burc...@gmail.com <burc...@gmail.com> wrote: > Hi Russell, > > My writing style sometimes is really clumsy. I'm sorry about that. > > You might look at the end of the first message in the thread. > Or maybe the thread topic. > > The problem is that half of third party plugins write: "after install, > add this and this and this to settings.py". > The problem is that I have reusable applications and they have their > bits of default configuration, have their own options. > > Problem is that some of such settings are additive, like > MIDDLEWARE_CLASSES, DATABASES or DATABASE_ROUTERS, and you wanted to > give an app the possibility to configure their part of global > configuration, but not override settings which are set by another > applications. > > Problem is that, like everybody, I have different machines where i run > my projects, and they have different settings (DEBUG, DATABASES, etc). > > I'm not the first here. The problem and the common ways to solve it > are already observed in Django wiki under > http://code.djangoproject.com/wiki/SplitSettings section.
And, as the wiki says: """ We don't need a default solution for this. It's not within the scope of this project to tell people how they should organize their settings files. Take that opportunity to showcase your individualism. """ I agree with Adrian -- this isn't an area where a complex set of builtin tools will improve the situation. Every situation will have slightly different requirements. The good thing about Django using Python for configuration is that just about anything is possible. That said, there are some common patterns, and we should do a better job at documenting these patterns -- if only to highlight how flexible the configuration system can be. > Probably, the problem with additive settings is the hardest one here. > Currently I don't see any alternative solution better than my. The wiki page you mention lists half a dozen approaches, and still doesn't mention the obvious option: from submodule.settings import * I'm simply not convinced that this is as big a problem as you make out. I have some large projects with lots of apps and lots of settings, but with some organizational discipline and the use of python imports, I've been able to manage that complexity. The only area in this that I might concede that there is need for major improvement is in applications providing default values for their own settings (i.e., contrib.admin default settings should be defined by contrib.admin, not in global_settings.py). However, I don't think this requires the introduction of a complex setting autodiscovery process -- it just requires a convention about where default values can be placed in an app so that they will be picked up by the settings initialization process. In fact, I would almost argue that it's a *good* thing that it's hard for applications to add default settings -- I'm not a big believer in the dictum that more settings necessarily make things better. Settings are required to point applications at specific services, or to configure specific extension points. However, IMHO, an application that requires dozens of carefully configured settings is often an indication of a poorly designed app. As for 'application configuration files' -- I think this is a misnomer. Whenever you deploy a Django project, you're deploying a project -- an amalgam of multiple apps. There's no such thing as the configuration for a single app. All apps are potentially dependent on other apps -- consider the potential impact of middleware and context processors on the operation of any application. When you configure a Django project, you really are configuring the entire project, specifying the interaction of the many parts as a whole; having a conceptual single project-level configuration file drives home this fact. 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.
