I find the value of separate settings modules is not splitting them by topic, but overriding them in specific contexts, like staging, production and development. Your implementation (and, I think, any solution that compiles multiple settings modules independently) don't have a way to specify orderings in a non-magical way. That's why I prefer explicitly importing some common settings into one module and overriding them piecemeal. The Zen of Python says "Explicit is better than implicit" and I think that is the case here. Packages provide settings and reasonable defaults. If you want to modularize them, you are free to do so yourself. I think composing settings internally is just added complexity for little benefit.
Best, Alex Ogier On Wed, Mar 13, 2013 at 12:27 PM, Omer Katz <omer.d...@gmail.com> wrote: > Lately I implemented some changes for django's settings module . > I refactored the whole module in order to have more extension points. > With #20040 <https://code.djangoproject.com/ticket/20040> it is now > possible to inject the Settings class that will be used by the LazySettings > object and I introduced a new class called SettingsCollector that allows > the developer to costumize how django will collect it's settings. > This enabled me to write the real code that will allow loading the > settings either as a package or as a module. > Instead of having one big monolitic settings.py you can now have a package > that has configuration modules that are seperated by topic. > If #20040 is accepted I can work on the new SettingsCollector that will > either try to load a settings module or package. > Should the new default be a package or a module? If it's a package it > means we should also change the project_template. > This is the working prototype <https://gist.github.com/thedrow/5153782>that I > wrote before I thought about creating a new SettingsCollector class. > To test it just call monkey_patch() in your manage.py. > We might want to allow multiple modules and packages to be loaded. > This will help us actually use the settings_local.py in a standard way. > What do you guys think? Am I clear enoguh? Should I explain in more detail > what am I thinking here? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
