4 ms·

This isn't wrong advice but their tone of authority seems a bit misplaced. 1. Make settings.py a package 2. Please do not put anything more than imports in __

This isn't wrong advice but their tone of authority seems a bit misplaced. 1. Make settings.py a package 2. Please do not put anything more than imports in __init__.py since you are adding logic downstream. 3. Use django environ https://github.com/joke2k/django-environ https://github.com/joke2k/django-environ which gives you a defined schema of your environment needs with casting and default values when needed. Now you keep your .env files, keep your setting overrides (settings/base.py, settings/local.py, etc) when needed AND you have defined a schema with non-string types for your environment variables. From the readme you can see how you make a schema with a casted type and default value: env = environ.Env( DEBUG=(bool, False) )

senko 5y ago
OP here. There are different styles you could go about, all of them having in common that you wan't to pull things from .env nicely. I personally don't prefer django-environ because it's a bit too verbose/magical for my tastes, so use python-dotenv. I would recommend against using `local.py`. It's easy to overcomplicate things here and one of the things I worry about is how easy it is to have a new person set the project up and start working on it. So, in general, absolutely agree with you. Details (which package to use and how exactly to set up the layout) are always going to be preference-based. Or at least until the nice folks from Black alleviate us from that pain as well :)
- leetrout 5y ago
  Sure. Claiming "too verbose/magical" for a library that adds structure to generally unstructured, smattered config data seems a bit misplaced. You are entitled to your opinion but I don't think trying to defend your stance with homemade env parsing functions while writing an authoritative sounding blog post helps the community as a whole when there are sound libraries and patterns that solve this exact problem.
whalesalad 5y ago
That’s how I do it. .env files are terrible if you’re using them with a language specific loader. The entire point of env is that it’s an abstraction you can manipulate externally. You can setup the env, then launch the program. It allows for runtime changes. https://whalesalad.com/blog/doing-python-configuration-right https://whalesalad.com/blog/doing-python-configuration-right You can do it right without packages or external dependencies.
- pphysch 5y ago
  Scrolling through the thread, this is my favorite so far. I like that it avoids counterproductive dependencies for loading a dotfile within the app. This is an operation that should be done at the same level as launches the Python interpreter, and Python should then complain if required envs are not set.
yourcelf 5y ago
While we started off using `django-environ` to help manage environment-based/12-factor settings, we've moved away from it in favor of django-classy-settings. The biggest knock against django-environ is that it does not treat the `.env` syntax the same as Docker or bash -- meaning that the same environment file can't be reliably used to provide variables for both the container and Django. django-classy-settings has been a joy to use, and its code is really simple and readable (~150 lines). [0] https://github.com/funkybob/django-classy-settings/ https://github.com/funkybob/django-classy-settings/
- amanzi 5y ago
  Have you got any examples of where the same .env file can't be used for both Docker and Bash? This is exactly how I do it in my django projects and haven't yet run into any issues.
  - yourcelf 5y ago
    `django-environ` makes a fairly simple effort[1] to strip starting/ending quotes off of literals. This will set the value of MY_VAR to the string `foo` (with doublequotes removed) in django-environ: MY_VAR="foo" Docker does not do any quote parsing. For this same env file, it will set the value of the variable to `"foo"` (retaining the doublequotes in the value). Bash, of course, requires quotes if the variable contains any special bash characters (for example, literal JSON with curly brackets), but its quote handling is much more complex. django-environ doesn't interpret bash code; it just does simple quote chomping. There's no reliable .env syntax you can use that works in all 3 of django-environ, Docker, and bash; and any variable that should start and end with quotes that are not stripped off can't be expressed in a way that both Docker and django-environ will read in the same way. This may seem like a nit-picking edge case, but it's indicative of the design philosophy in django-environ of trying to be "helpful", but in ways which lead to subtle confusion. The way it guesses the path to your `.env` file is another example. [1] https://github.com/joke2k/django-environ/blob/main/environ/environ.py#L821-L831 https://github.com/joke2k/django-environ/blob/main/environ/e...
    - 5y ago

senko 5y ago

OP here. There are different styles you could go about, all of them having in common that you wan't to pull things from .env nicely. I personally don't prefer django-environ because it's a bit too verbose/magical for my tastes, so use python-dotenv. I would recommend against using `local.py`. It's easy to overcomplicate things here and one of the things I worry about is how easy it is to have a new person set the project up and start working on it. So, in general, absolutely agree with you. Details (which package to use and how exactly to set up the layout) are always going to be preference-based. Or at least until the nice folks from Black alleviate us from that pain as well :)

leetrout 5y ago
Sure. Claiming "too verbose/magical" for a library that adds structure to generally unstructured, smattered config data seems a bit misplaced. You are entitled to your opinion but I don't think trying to defend your stance with homemade env parsing functions while writing an authoritative sounding blog post helps the community as a whole when there are sound libraries and patterns that solve this exact problem.

whalesalad 5y ago

That’s how I do it. .env files are terrible if you’re using them with a language specific loader. The entire point of env is that it’s an abstraction you can manipulate externally. You can setup the env, then launch the program. It allows for runtime changes. https://whalesalad.com/blog/doing-python-configuration-right https://whalesalad.com/blog/doing-python-configuration-right You can do it right without packages or external dependencies.

pphysch 5y ago
Scrolling through the thread, this is my favorite so far. I like that it avoids counterproductive dependencies for loading a dotfile within the app. This is an operation that should be done at the same level as launches the Python interpreter, and Python should then complain if required envs are not set.

yourcelf 5y ago

While we started off using `django-environ` to help manage environment-based/12-factor settings, we've moved away from it in favor of django-classy-settings. The biggest knock against django-environ is that it does not treat the `.env` syntax the same as Docker or bash -- meaning that the same environment file can't be reliably used to provide variables for both the container and Django. django-classy-settings has been a joy to use, and its code is really simple and readable (~150 lines). [0] https://github.com/funkybob/django-classy-settings/ https://github.com/funkybob/django-classy-settings/

amanzi 5y ago
Have you got any examples of where the same .env file can't be used for both Docker and Bash? This is exactly how I do it in my django projects and haven't yet run into any issues.
- yourcelf 5y ago
  `django-environ` makes a fairly simple effort[1] to strip starting/ending quotes off of literals. This will set the value of MY_VAR to the string `foo` (with doublequotes removed) in django-environ: MY_VAR="foo" Docker does not do any quote parsing. For this same env file, it will set the value of the variable to `"foo"` (retaining the doublequotes in the value). Bash, of course, requires quotes if the variable contains any special bash characters (for example, literal JSON with curly brackets), but its quote handling is much more complex. django-environ doesn't interpret bash code; it just does simple quote chomping. There's no reliable .env syntax you can use that works in all 3 of django-environ, Docker, and bash; and any variable that should start and end with quotes that are not stripped off can't be expressed in a way that both Docker and django-environ will read in the same way. This may seem like a nit-picking edge case, but it's indicative of the design philosophy in django-environ of trying to be "helpful", but in ways which lead to subtle confusion. The way it guesses the path to your `.env` file is another example. [1] https://github.com/joke2k/django-environ/blob/main/environ/environ.py#L821-L831 https://github.com/joke2k/django-environ/blob/main/environ/e...
  - 5y ago