Home/ Questions/Q 3342260
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T00:49:04+00:00

I’m a strong proponent of version control, and am starting work on a Django

  • 0

I’m a strong proponent of version control, and am starting work on a Django project. I’ve done a few before, and have tried a few different approaches, but I haven’t yet found a decent structure that I actually feel comfortable with.

Here’s what I want:

a) Source code checked into version control

b) Preferably the environment is not checked into version control (something like buildout or pip requirements.txt is fine for setting up the environment)

c) A reasonable “get a new developer going” story

d) A reasonable deployment story – preferably the entire deployment environment could be generated by a script on the server

It seems to me like someone has to have done this before, but many hours of searching have all led to half-baked solutions that don’t really address all of these.

Any thoughts on where I should look?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I keep a projects/ directory in my home directory (on Linux). When I need to start a new project, I make a new, shortly-named (that sufficiently describes the project) dir in projects/; that becomes the root of a new virtualenv (with –no-site-packages) for that project.

    Inside that dir (after I’ve installed the venv, sourced it, and installed the copy of django I’ll be working with), I “django-admin.py startproject” a subdir, normally by the same short name. That dir becomes the root of my hg repo (with a quick hg init and ci), no matter how small the project.

    If there’s any chance of sharing the project with other developers (a project for work, for example), I include a pip requirements.txt at the repo root. Only project requirements go in there; django-debug-toolbar and django-extensions, staples for my dev workflow, are not project requirements, for example. South, when we use it, is.

    As for the django project, I normally keep the default settings.py, possibly with a few changes, and add the local_settings convention to the end of it (try: from local_settings import *; except ImportError: pass). My and other devs’ specific environment settings (adding django-extensions and django-debug-toolbar to installed apps, for example) go in local_settings.py, which is not checked in to version control. To help a new dev out, you could provide a template of that file as local_settings.py.temp, or some other name that won’t be used for any other purpose, but I find that this unnecessarily clutters the repo.

    For personal projects, I normally include a README if I plan on releasing it publicly. At work, we maintain Trac environments and good communication to get new devs up to speed on a project.

    As for deployment, as rz mentioned, I hear fabric is really good for that kind of automated local/remote scripting, though I haven’t really taken the chance myself to look into it.

    For the uninitiated, a typical shell session for this might look like the following:

    $ cd ~/projects/
$ mkdir newproj
$ cd newproj/
$ virtualenv --no-site-packages .
$ source bin/activate
(newproj)$ pip install django django-debug-toolbar django-extensions
... installing stuff ...
(newproj)$ django-admin.py startproject newproj
(newproj)$ cd newproj/
(newproj)$ hg init .; hg ci -A -m "Initial code"
    • 0