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.

Reply via email to