Setting Environment Variables Locally for Django Development

While reading the book "Two Scoops of Django", I learned many useful things about Django. One of the really useful tips in chapter 5 of the book is the isolation of secrets (e.g. API keys and database passwords) from the source code repository, through the use of environment variables. The concept is great, but I think there is a better way for setting the environment variables on your local development machine.

The book says to put the environment variables in .bashrc, .profile, or .bash_profile, or to put them in the bin/activate script of the virtualenv. This approach is not ideal, for the following reasons:

Using .bashrc and friends means that your API keys and database passwords are always loaded whenever you use the shell, even when you don't mean to work on your Django project;
In the long run, it contaminates your shell environment with useless environment variables as you work on more and more projects;
At the same time, you will likely be forced to prefix the environment variable names with your project names, to prevent conflicts, making the names longer than necessary;
You have to manually clean up your .bashrc (or its equivalent) after your project's end-of-life.
You have to use different syntaxes as you migrate between Linux/Unix/Mac and Windows

Even if you go with bin/activate, you are still exposing your API keys and database passwords to the shell, and you have to clean them up in the deactivate function. It's troublesome and mistake-prone. This is actually a consequence of how virtualenv is doing it wrong.

So here is my approach, which I believe is an improvement:

In the site-packages directory of your virtualenv (something like "lib/python2.7/site-packages/"), define a new mysecrets.py module. The content of this module is like this:

# `secrets` **must** be a simple dictionary.
# i.e. no logic to programmatically generate keys or
# values.
secrets = {
    'postgresql_username': 'bob',
    'postgresql_password': '132!^a8!#)',
    # etc
}

Then, in the settings/local.py module of your Django project, import this mysecrets.py module and use the secrets function:
```
from .base import *
import mysecrets

SECRETS = mysecrets.secrets

# The rest of the usual content in local.py…
```

Now the SECRETS dictionary is even accessible through the django.conf.settings object.

This approach deals with the problems above while still achieving the effect of isolating secrets from the source code repository:

It is shell-agnostic because you are using Python to declare environment variables, and you certainly already know Python since you are working on a Django project;
You don't leak your secrets through your shell;
You don't contaminate your shell environment with useless variables;
You don't have to prepend your variable names with your project name;
You don't have to manually edit .bashrc (or its equivalent) in order to clean up, after your project's end-of-life. You would probably delete your project's virtualenv anyway.
You don't have to edit the deactivate function in bin/activate to clean up the environment.

Update

@pydanny is concerned that this approach may degenerate into the local_settings.py anti-pattern. While his concern is understandable, I perceive it as a matter of good sense and self-discipline. Like I said in this thread in the Hong Kong Python User Group, anybody who has read @pydanny and @pyaudrey's Two Scoops of Django should understand the intention of isolating secrets while keeping all the real logic under version control. The module is purposely named mysecrets.py; anybody who adds anything other than secrets (e.g. API keys and database passwords) into this module simply fails English and should not be programming in any programming language at all. Like the old saying goes: we are all consenting adults.

An even safer approach would involve writing Windows INI-style config files and using Python's ConfigParser to parse them, as suggested by Jimmy Wong. While this avoids the degeneration into the local_settings.py anti-pattern, it also entails knowing and using an extra syntax (INI-style config file syntax), however trivial it is. It's a trade-off that I am hesitant to take. I'm lazy this way.

Comments are most welcome.

Update 2

I don't remember why I originally wrote `secrets` as a function. In retrospec, it should be just a dictionary. It would look more declarative and be less prone to degenerate into the local_settings.py anti-pattern. I've updated the code snippets above.

Related Posts:

Comments