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. Probably, the problem with additive settings is the hardest one here. Currently I don't see any alternative solution better than my. However, GSoC app loading project could change situation drastically, and maybe in the end of summer I'll change my mind of the better solutions for configuration problems. But currently it aims to change the way how per-application-instance settings are set, not global settings. In the opposite, I'm interesting mainly in splitting global settings into different modules. Also please note, that the more different applications you want to reuse, the more recognizable the problem is to you. I don't try to accuse you that you don't seem to have a lot of reusable applications in your projects -- you might already use some of the methods described in SplitSettings wiki page, or you're just a fan of big settings.py file -- I'm just telling you that I'm a big fan of modular projects, and have dealt with them a lot, and so I wanted to have really good and obvious solution for the configuration problem. On Fri, Jun 4, 2010 at 7:04 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Thu, Jun 3, 2010 at 11:19 PM, burc...@gmail.com <burc...@gmail.com> wrote: >> Hi all, >> >> I've written a prototype, and put it on >> http://github.com/buriy/django-configurator. >> It has few good design decisions, and few maybe not that good. >> Anyway, I consider it as a good addition to app loading GSoC Proposal, >> which is currently being worked on. > > Hi Yuri, > > I might be missing something really obvious, but I can't make any > sense out of your proposals. After two quite lengthy emails, I haven't > even been able to work out what what problem you are actually trying > to solve. > > Your initial proposal consisted of pages of snippets of configuration, > but no explanation of how those pieces fit together (or at least, I > couldn't follow it). It might be helpful if you step back from the > details and try to give a big picture view of what you're trying to > do. > > 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.