Hi all,
On Wednesday, April 13, 2016 at 9:58:18 PM UTC+2, Carl Meyer wrote:
>
> Hi James et al,
>
> In general, I like the idea of adding a helper to Django to read
> settings from the environment. I think this helper should be kept as
> simple and non-magical as is reasonable. Thus:
>
> This sounds great. Django should not do anything magical and just in one
way.
Just give the tool to the developers.
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.
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.
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 default value for default database URL
SOME_USER_KEY2=a default value for default database 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)
Thanks for reading and sorry for my English. I hope you understood the idea.
Marcin
--
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/6dbaaaca-8de7-49d3-a7b8-df011b94f147%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
