> On 11 Apr 2016, at 19:39, Curtis Maloney <cur...@tinbrain.net> wrote:
>
> 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.
There’s an additional complexity here.
Usually, it’s best for settings read from environment variables:
a. To use a default value in dev, even if that means a small degradation in
functionality. This allows developers to start working on the project without
adding dozens of exports to their $VIRTUAL_ENV/bin/postactivate, and to add
just the values they need when they work on specific parts like integrations
with third-party systems.
b. To crash if no value is provided in prod, in order to catch configuration
errors upfront.
One might think of switching the behavior depending on settings.DEBUG, but
that won't work because the switch is required to load settings properly.
I’ve seen lots of wrapper that don’t add enough value to be worth it. These
days I just write:
# settings/base.py
...
# settings/dev.py
FOO_TOKEN = os.environ.get('FOO_TOKEN', '')
# settings/prod.py
FOO_TOKEN = os.environ['FOO_TOKEN']
It isn’t as dry as it could be, but at least it’s simple.
--
Aymeric.
--
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/A0573632-AE0B-4243-AA63-4462C5596D75%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
