Using Revision Control on a Django Project Without Revealing Your Passwords

Just a quick post today, since this took me way too long to figure out. If you have a django project that you want to share without sharing the private bits of settings.py, there is an easy way to do this.

I tried for a while to to set up mercurial hooks that would strip out my passwords before each commit, and then place them back after each commit, thus avoiding uploading them publicly. This does not work however because all of the mercurial hooks happen after snapshots of the modified files have been made. So you can edit the files using a hook, but your edits will only go into effect upon the next check in. Clearly, this will not do.

Another solution that I tried was the mercurial keyword extension. This could work, but ultimately it does not because you have to remember to run it before and after each commit — something I know I'd forget sooner or later.

The solution that does work is to split up your settings.py file into multiple pieces such that there is a private file and a public file. I followed the instructions here, with the resulting code looking being checked in here and here. There is also a file called "20-private.conf" which is not uploaded publicly, and which contains all the private bits of code that would normally be found in settings.py. Thus, all of my settings can be found my django, but I do not have to share my private ones.

I just did a project that used this technique, but for a different purpose - we had multiple people working on the same code trunk with subversion, and each person had the common settings.py file, plus a local_settings.py file that was execfile'd in the same way you describe. That meant that an individual could have settings like:
- turn on debugging
- use a different MEDIA_ROOT
- use a local database, instead of one on the server
- etc.

all in the local_settings.py file, which could include overrides to the common settings.py file. Worked quite well.

Yeah, it's a pretty slick technique. I actually disagree with the wiki author linked to above in that I think django should have something similar in its settings by default. It would demonstrate the flexibility without adding too much more complexity.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.