Cookiecutter-django: What is the reasoning behind DJANGO_READ_DOT_ENV_FILE?

[svleeuwen]

Since this commit, the .env isn't loaded without manually setting DJANGO_READ_DOT_ENV_FILE.

The comment states:

.env file, should load only in development environment

I don't really agree with this since we use .env files extensively on production servers. Not a big problem as we can easily add DJANGO_READ_DOT_ENV_FILE to the supervisor config. But I don't understand what problem it fixes.

For local development this is a bit cumbersome. There's no documentation explaining the need to set this variable. I'd expect it here for example.

This env variable also isn't set in local docker config (dev.yml), disabling the possibility to overwrite settings via a .env file.

[pydanny]

I don't bother with .env so I'm not the person who can answer your question. Perhaps @jayfk or @webyneter or @luzfcb can weigh in?

[jayfk]

Honestly, I don't even know. There were some people complaining about not being able to use the .env file on vanilla Python so the DJANGO_READ_DOT_ENV_FILE environment variable was invented.

[webyneter]

@svleeuwen, see #985

[tmilovan]

I understand that, but since you will mostly use Cookiecutter Django to instantiate project in development environment it may be handy to have reading of .env file turned on by default or maybe even better add the possibility to choose the setting in cookiecutter script.

[pydanny]

I do not use the .env file in development so I do not want it turned on by default.

Keep in mind I'm not too happy with how django-environ manages the .env file behavior, as I know it's confusing and annoying. At some point I may give up and we'll implement something of our own.

[sebastian-code]

Are you given though to this on replacing django-environ with another package or to develop an inhouse implementation?

If the alternative is to incorporate another package, which one would be a good candidate?

[pydanny]

Are you given though to this on replacing django-environ with another package or to develop an inhouse implementation?

Replacing this package will be a lot of work. Except for some edge cases, it works okay, so why spend the effort? Also, I would rather piggy back of a package then invent something new that has to be maintained. Unless there's a pressing need, and funds to support the reviews by core maintainers are made available, we're not switching.

If the alternative is to incorporate another package, which one would be a good candidate?

Why don't you do the research yourself instead of asking others to volunteer their free time? Compare a dozen options for suitability, summarize the ones you think are good, and suggest the best three in a separate issue.

[sebastian-code]

What I was really looking for was perhaps a slightly more interesting conversation and perhaps some introspection about the previous experience some of you might have on the subject; but leaving aside the disobliging response and to abandon the line of argument and focus on something that is worth the time:

I had already done some work on this, testing some of the packages that available out there, and wanted to listen to the opinions of those who had tried the same process before:

EnvParse - It requires a lot of legwork with its _preprocessors_ which makes the implementation much harder than it should be, and the project is inactive.
Honcho - Mainly focused on Procfiles, and the things it involves.
python-dotenv - This package looks promising but only reads the variables and assign them in memory; you still require to capture them with os.getenv, additionally, it looks like the package does not parses database addresses in URI format.
python-decouple - Lacks a proper database URI workflow and to solve it they suggest to use an additional package, the project is actually inactive.
django-dotenv - Haven't tested it, but it looks like needs to be loaded into the WSGI process, which perhaps hurts the possibility to implement django-channels, the project is inactive.

[jeffcjohnson]

I was just looking to see how I could use the .env file in dev automatically without needing to define the DJANGO_READ_DOT_ENV_FILE environment variable. This little hack in config/settings/local.py seems to do the trick nicely. I figured it might give the next person a head start. If there is a better way please let us know.

config/settings/local.py

import socket
import os
os.environ["DJANGO_READ_DOT_ENV_FILE"] = "true"
from .base import *  # noqa

[luzfcb]

@jeffcjohnson nice trick

[luzfcb]

prettyconf - PrettyConf is a Python library created to make easy the separation of configuration and code following the recomendations of 12 Factor's topic about configs. It is strongly inspired in python-decouple and both provides a similar API. (The project is active, and the code stable.)

[philippeluickx]

My 2 cents:
In hosted PaaS environments (such as Heroku, AWS), you set environment variables through CLI or other means. Typically this is not done through an .env file. I am +1 on keeping the solution as is.

[jarod51]

I do not use the .env file in development so I do not want it turned on by default.

Keep in mind I'm not too happy with how django-environ manages the .env file behavior, as I know it's confusing and annoying. At some point I may give up and we'll implement something of our own.

Hello

How/Where do you store your DB connection strings then ? What if you have two different dev environment which need different settings ?

[luisroel91]

I do not use the .env file in development so I do not want it turned on by default.
Keep in mind I'm not too happy with how django-environ manages the .env file behavior, as I know it's confusing and annoying. At some point I may give up and we'll implement something of our own.

Hello

How/Where do you store your DB connection strings then ? What if you have two different dev environment which need different settings ?

Did you ever figure this out by any chance...?