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:
- I'm in favor of a flexible helper function that can be manually used
in a settings file to read an explicitly-named env var and coerce it
using any arbitrary callable (that gives enough power to "coerce" using
something as simple as `int` or something as complex as
`parse_database_url` that turns a DSN string into a Django db dict),
with some handling of defaults. Below I give some usage examples of the
function I use for that, and link to its code.
- I'm opposed to anything more magical than that, e.g. anything that
tries to set up an all-dancing automatic mapping or translation between
env var names and setting names, or tries to enforce some particular env
var prefix. The minor gains in conciseness with this kind of thing
aren't nearly worth the losses in flexibility in how you construct your
settings file or name your env vars.
- I'm also opposed to conflating the issue of reading env vars with
orthogonal stuff like class-based settings or patterns for using
multiple settings files.
More comments (and sample code) below:
On 04/11/2016 12:26 PM, Aymeric Augustin wrote:
>> 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 totally agree with all this. My projects have a separate MODE setting
which is either 'dev' or 'prod', and I use a utility to read settings
from the environment which supports variable defaults (or lack of
default) by mode, exactly as you outline above. Specifically, it works
like this:
env = EnvParser('PRJ_MODE')
SECRET_KEY = env('PRJ_SECRET_KEY', default={'dev': 'dev-secret'})
The effect of this is that the mode ('dev' or 'prod') will be read from
the `PRJ_MODE` env var (usually `PRJ` would be a short code specific to
the project name). Then if the mode is 'dev', no `PRJ_SECRET_KEY` env
var is required, and 'dev-secret' will be used as the default. But if
the mode is 'prod', the server will fail to start up unless
`PRJ_SECRET_KEY` is found in the environment.
I wrote this to allow for any number of arbitrarily-named modes, but in
practice I've never used anything but 'dev' and 'prod' (staging and demo
sites are generally set up as 'prod'). Hardcoding to those two modes
would perhaps allow a nicer syntax for specifying defaults, by using
separate kwargs instead of the dict.
Anyway, FWIW, here's the code I use:
https://gist.github.com/carljm/69b8e351dac87f4c3f5b440632727fdb
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/570EA4C6.6080700%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
