Also don't you guys think that the SettingsCollector class will simplify the implementation of django-configurations for example?
בתאריך יום רביעי, 13 במרץ 2013 19:27:02 UTC+3, מאת Omer Katz: > > 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.
