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