> 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.