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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
