runserver - read environment variables from a .env file

[Dražen Lučanin]

Just bumped into ​this cool project to adhere to the 12-factor app philosophy where server-specific settings are read from environment variables. I'm wondering if there's an easy way to get ./manage.py runserver to also read environment variables from a .env file, so that I don't have to resort to some shell/.bashrc trickery on every server? For example ​honcho supports this, but then I don't have the server auto-refresh whenever I edit the source.

[Tim Graham]

It's not clear to me why you need this. runserver shouldn't be used in production and I don't think we're going to add more features to it, but I'll leave the ticket open in case you'd like to elaborate further.

[Dražen Lučanin]

OK, yeah, I think I might not have been too clear. So, ​the 12-factor app clause is that on servers, you should be able to control the relevant configuration using environment variables, as it's easy to manage this using e.g. ansible, salt or the heroku cli. The .env file is used on a local dev machine to not have to set up these environment variables in your .bashrc for every project. This is already supported by process launchers such as foreman and honcho (​relevant honcho and ​foreman docs), but while developing we probably want to use ./manage.py runserver, as it auto-refreshes on code changes. Now, I'm suggesting a -e <envfile> option (and implicitly reading variables from a .env file if it's present) that would set the relevant environment variables for the launched process, to be able to keep the same workflow with runserver too.

[Tim Graham]

It makes sense, but couldn't you do something like add some logic in your development settings file to parse and set the variables? It may not be the most elegant solution, but I'm hesitant to add more logic to runserver for this purpose.

In the long run, we've thought about replacing runserver with something like gunicorn (#21978) since as a web framework, our focus shouldn't be on building web servers.

I did notice that gunicorn has ​an option for passing environment variables (although not reading them from a config, it appears).

Anyway, that's just my 2 cents, we'll see what others think.

[Claude Paroz]

I'd rather see this as a complementary Django application (subclassing runserver). Not everyone adhere to the 12-factor app philosophy, and I'm not fond of adding new code in Django each time a new trend is in the air (no offense intended). I'm personally rather on the minimalist side of things.