Just to throw another voice in here, I'm currently using django-environ[1],
as mentioned by Sean Brant. In addition, I'm using a settings setup based
on cookiecutter-django[2]. This means having my settings split into
`config.settings.common`, `config.settings.local`,
`config.settings.production`, for example. In common, I have things like
the following:
DATABASES = {
# Raises ImproperlyConfigured exception if DATABASE_URL not in
os.environ
'default': env.db("DATABASE_URL"),
}
EMAIL_BACKEND = env('DJANGO_EMAIL_BACKEND',
default='django.core.mail.backends.smtp.EmailBackend')
# ...etc...
These would obviously propagate up and be used in the production settings.
Then in the local settings, I have things like:
SECRET_KEY = env('DJANGO_SECRET_KEY', default='CHANGEME!!!')
EMAIL_BACKEND = env('DJANGO_EMAIL_BACKEND',
default='django.core.mail.backends.console.EmailBackend')
DATABASES = {
'default': env.db('DATABASE_URL',
default='postgis://django:supersecretpassword@localhost:5432/django'),
}
# ...etc...
I don't know if this is all necessarily the best way to do it, but it has
been working quite well for me. Everything is read out of a .env file, and
I provide a template.env file in my project to show which values need to be
set in there. `DJANGO_SETTINGS_MODULE` defaults to production, so that
missing environment keys will raise alarms by default, and then when
possible, those keys become optional in development settings.
-Joey
[1]: https://github.com/joke2k/django-environ
[2]: https://github.com/pydanny/cookiecutter-django
On Mon, Apr 11, 2016 at 10:39 AM, Curtis Maloney <cur...@tinbrain.net>
wrote:
> Just want to throw my 3c in here...
>
> Firstly, for reference, I wrote django-classy-settings to help with
> various settings related problems, one of which being env-based setting.
>
> https://github.com/funkybob/django-classy-settings
>
> As my env decorators are written to be class properties, they don't quite
> fit this discussion... however, things to consider:
>
> 1. All env vars can have a fallback value (the method in my case)
> 2. You can mark an env var as not having a fallback value, and it will
> raise an error at start up if not set.
> 3. Non-trivial value types are not easy.
>
> The URL series of settings helpers deal with many of these cases fairly
> well, as they allow us to specify a backend (protocol), username, password,
> host, port, and positional and keyword arguments.
>
> Registering more protocols is actually quite easy, all told.
>
> However, it becomes tricky when we allow multiples, such as database and
> cache backends. Do we settle on, for instance, a pattern of
> "DJANGO_DATABASE_{name}="? Or some other scheme?
>
> Email settings are certainly another big one, IME... as well as AWS keys...
>
> --
> C
>
> --
> 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/570BE142.3000209%40tinbrain.net
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CADBkHdK5yhxWoDB6yygnFC%2BfmPCn3n6x%3DJoxbym2HuTJ3oyDVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
