Hi Marcin, On 04/26/2016 08:12 PM, Marcin Nowak wrote: > But I would like to say my thoughts about "settings" itself. > They were good (simple) before incuding nested dictionaries. > After switching to dicts the settings handling went harder way.
I agree that settings grouped into dicts are harder to manage than flat
settings. Django has not made any "switch to dicts" for settings; in
fact, the last time we had to make a decision between a group of flat
settings with a common prefix vs a dict, we chose flat (the SECURE_*
settings).
> As a example I can tell about reconfiguring LOGGING for dev/live settings.
> We're tuning them via direct changes like
> LOGGING['loggers']['some-logger']['level']='...'
> which is very error prone. The flat settings are easier to maintain.
LOGGING is a special case; this dict format is not defined by Django,
but by Python's logging module and its "dictConfig" function.
> Nested settings are good for framework internals and should stay in that
> form,
> but maybe solution for end users and ENV integration is flattening
> settings again, at the high-level?
>
> Let's imagine something like INI file which is parsed somehow and
> converted to internal settings object.
> The INI file has a shallow structure (options grouped in sections),
> can be easily extended / overrided / included (look at Buidout as an
> example),
> and ENV keys will be related to flat INI instead of nested settings.py.
>
> Let's consider an example:
>
> |
> [databases]
> default.url =postgres+psycopg2://user:pwd@localhost:5432/exampledb
> default.engine =django.db.backends.postgres_psycopg2
>
> |
>
> which can be simply reconfigured by ENV vars like:
>
> DJANGO_DATABASES_DEFAULT_URL="postgres+psycopg2://user:pwd@localhost:5432/exampledb"
> DJANGO_DATABASES_DEFAULT_ENGINE="django.db.backends.postgres_psycopg2"
>
> OR add some preprocessing and flexibility:
>
> |
>
>
> [databases]
> default.url =${env:SOME-USER-KEY1}
> default.engine =${env:SOME-USER-KEY2}
>
>
> [env]
> SOME_USER_KEY1=a defaultvalue fordefaultdatabase URL
> SOME_USER_KEY2=a defaultvalue fordefaultdatabase engine
>
> |
>
> where [env] section will by filled automatically by Django from os.environ.
>
> This also gives a possibility to extend settings.ini via development.ini,
> where [databases] can be overridden with developer settings (without env
> access)
I've done something similar before, and I think it's fine, but this is
an example of precisely the sort of more-magical opinionated approach to
settings that I don't think belongs in Django core; it's perfectly
possible to implement it as a third-party package on top of Django's
current settings handling, for those who like it.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/5720E786.7020306%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
