Django project skeleton
Django has all the necessary tools to easily create a project, and your first app. But first you need to have Django installed. Do you want to install it system wide? How about all the dependencies your project will have? And then there is the release pain when you want to relese one of your Django apps to the public.
The benefit in this skeleton is that it makes development of re-usable Django apps really easy.
Features in this skeleton:
- Uses Buildout
- Separate Python eggs for each Django app
- Test runner for easy CI integration
- Setting files for development and production
- django-sentry for error reporting
- South for database migrations
- Supervisord for process management
This work is based on the ideas presented in Developing Django apps with zc.buildout by Jacob Kaplan-Moss.
Maintaining the project
The project bootstrapping, deployment and sandboxing is handled by Buildout.
There's also bootstrap.py in the repo which can be used to install buildout locally in the project directory if you don't want to install it system wide.
Buildout handles downloading and installing of all dependencies the project needs. Dependencies can be written in the buildout.cfg file, but Buildout is so clever that it collects the dependencies also from the apps we are developing. This makes it easy to develop self-containing apps even when they are in the same directory tree with the rest of the project.
Django is not specified as a dependency in the buildout.cfg file as it is provided by djangorecipe.
Developing multiple apps
At first the coding begins in a single repo, just like the Django tutorials explain. The developer doesn't need to pay any attention to the fact that all apps are also python eggs. When one of the apps reach a point that it is needed in another project, then that directory is split into a separate repository. Public releases are also easy as the egg machinery is there from the beginning.
Buildout makes it easy to switch between installing an egg from PyPi and using local source tree for the egg. When the egg is listed in the develop list in the buildout.cfg file the local copy of the source is used, otherwise it is searched from PyPi.
The directory tree looks like this:
├── doc ├── project │ └── assets │ ├── media │ └── templates └── src ├── foo │ └── foo └── runserver
The src directory contains the eggs. Directories src/foo and src/runserver have the setup.py file needed by all Python eggs. The foo app here is a placeholder, and a template, for your code.
Also the project directory is in the PYTHONPATH so it is possible to put views and other misc stuff in there if you need.
Usually development and production environments are little different. Sometimes more. But always it is best to have separate configuration to these two environments. As django settings file is normal python source file it is easy to customize the way it is loaded.
This skeleton uses a three file system. There is project/settings.py which contains the basics and all common settings to other variants. Then files project/production.py and project/development.py start with a line from project.settings import *. After that line it is just matter of overriding the defaults.
Monitoring and error reporting
We use django-sentry for monitoring and error logging. In this skeleton it is configured as a client only to send exceptions and all log messages to separate sentry instance. You can change this behaviour in project/production.py settings file.
To actually use this skeleton you should rename the parts that are now called foo. Mainly these are the egg name django-foo and the Python module foo the egg contains.
Starting the Django instance
Everything should magically just work if you run:
python bootstrap.py bin/buildout bin/django syncdb bin/django runserver
In the syncdb phase it asks for the admin account. After that the development server should be running and you can log in to http://127.0.0.1:8000/admin