Hi Russell, I strongly disagree with your and Adrian vision of whether conventions are good or not. But I won't comment that any further. There are your political decisions, and I have no single bit of control on them. I know that it's impossible to persuade you, so why should I spend my time doing this.
However, you didn't tell anything on the problem that was the main reason why I wrote this app. Additive variables. DATABASES, DATABASE_ROUTERS, MIDDLEWARE, etc. Do you think situation will change with them? In example, I want few of my apps to work with their own databases. They need to install their database into DATABASES and their router into DATABASE_ROUTERS. How would you do that? On Fri, Jun 4, 2010 at 7:57 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > 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. > > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
