All of the changes you describe are what I would call "magic". Magic has a
downside: it's hard to understand and debug. As it currently stands, Django
has exactly one form of settings magic: there is a DJANGO_SETTINGS_MODULE
environment variable that adjusts where the settings are found. This is
easy to document and point to. "My settings aren't working, what is going
on?" "Check DJANGO_SETTINGS_MODULE." "Why does this setting have this wonky
value that's not the default?" "Read the source code to your
DJANGO_SETTINGS_MODULE."
Everything you describe is possible to do yourself explicitly if you just
want it for your own app. Want to override from environment variables?
os.environ.get("VARIABLE", "default value"). Reading from ini files?
ConfigParser.SafeConfigParser("my.ini"). The database is tricky because you
can't use the ORM without a chicken-and-egg problem, but it would be even
more confusing if you *have to* import from django.conf (for BaseSettings)
but you *aren't allowed to* import from django.db.
django-configurations sits entirely in front of Django, which is the right
place for it to sit. Forcing everything through the narrow bottleneck of a
single settings module is *a good thing*. It makes things explicit and
debuggable. Other python frameworks have similar bottlenecks. Pylons has a
master config file (ini format) that you specify on the commandline, and
several python files in expected locations. Flask is less obvious, it has
no magic files at all, but at some point you make a project-wide instance
of flask.Flask and pass it to WSGI or a ./manage.py you write yourself and
you set config on it manually, for example
app.config.from_object("myapp.MyConfig").
The only reason for having these SettingsCollectors in core is to allow
redistributable apps like django-configurations to do magic. That is, so
they can say, "Install django-configurations, and suddenly every setting
can be overridden from the environment!" This seems like a bad idea, versus
"Install django-configurations, and now you have a new tool in your toolbox
to put in settings.py that imports from the environment!"
Best,
Alex Ogier
On Thu, Mar 14, 2013 at 3:42 PM, Omer Katz <omer.d...@gmail.com> wrote:
> 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.
>
>
>
--
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.
