[yourcelf]

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/

[amanzi]

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]

`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/e...