Why would you call them magic?
Why does allowing extensibility for those who need it is a bad idea?
You will be doing it explicitly anyway by providing a SettingsCollector
class to the Settings class' constructor.
If are doing it, you should know what you are doing.
. Is my code harder to debug or understand than the current code? I
strongly disagree here. The current Settings class clearly violates
SRP<http://en.wikipedia.org/wiki/Single_responsibility_principle>.
It holds the settings, validates them and collect them. What's not easy to
understand about SettingsCollector? You can understand by it's name what
exactly it does.
"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!""
Why exactly this is a bad idea? Since when extensibility is a bad idea in
software development?
You just say you are against it but you don't provide a good reason other
than it's easier to explain to others what's wrong if something is wrong.
The current behavior will stay as the default behavior *at least *until
Django 2.0 if not forever so "it's easier to explain to others what's
wrong" is not a valid argument in my opinion.
If you are writing your own SettingsCollector you probably know what you
are doing.
If we'll introduce other types of SettingsCollectors in Django then we
won't introduce them in the Getting Started documentation until a very late
stage so that newcomers can understand the default behavior but that's
another issue for later on.
For now I want to focus on the pull request itself.
Does the refactoring makes the code clearer in it's intension?
Does it allow extensibility when it is required?
Does it maintain the default behavior for most Django developers?
I believe that the answer to all of those questions is yes it does.
בתאריך יום חמישי, 14 במרץ 2013 23:56:31 UTC+3, מאת Alex Ogier:
>
> 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...@gmail.com<javascript:>
> > 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-develop...@googlegroups.com <javascript:>.
>> To post to this group, send email to
>> django-d...@googlegroups.com<javascript:>
>> .
>> 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.
