You haven't referred to the pull request. The pull request <https://github.com/django/django/pull/899> itself currently just refactors the settings module in order to have better extensiblity hooks and to clarify the code. The pull request introduced the SettingsCollector class which allows you to costumize how exactly the settings are collected. The LazySettings class now accepts a constructor parameter that allows you to switch the settings class. The Settings class allows you to replace the SettingsCollector class through a constructor parameter as well. The first question is if this refactoring is needed and welcome. In my opinion it is even if you don't need it. The simplest example is when you want an environment variable to always override a setting. You might want it because your database server is down and you want to at point to a backup server without changing the code and thus releasing a new temporary patch version or load all settings from an *,ini file, from the database and probably other scenarios I can't come up with right now (I'm after 3 glasses of wine :):). Django could supply multiple SettingsCollectors to choose from and keep the current beahvior for backwards compatibility until 2.0 if needed or until forever if the default behavior is desired. It enables much more room for flexability for developers who have a special need for different form of settings files. If I were to extend the SettingsCollector to support loading packages as well we might get a standard way to load settings for different environments. You can easily develop a common settings package or module for that matter and than override it with a specific package or module for each deployment using another SettingsCollector class. I see much benefit in this refactoring and I hope that it will be accepted. I hope I made my intentions clearer.
בתאריך יום רביעי, 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.
