Django Python

Copying Django Model Objects

Django’s ORM is top notch. It provides facilities to do almost anything you can think of with a database, and if it doesn’t, it still lets you execute arbitrary SQL to your hearts content. I’ve been developing Django for close to 2 years now, and still discover facets of it that I never knew existed. For instance, I had a need to duplicate a row in a table, but give it a different primary key. After a quick Google search, I discovered that Django allows you to do the following to copy instantiated model objects.

my_model = MyModel.objects.get(pk=4) = None

There are a few caveats with doing things this way.

  • Unique Constraints – If you have any unique constraints on the model, the save will not pass validation and fail.
  • ManyToMany Fields – If you need new copies of ManyToMany field values, you’ll need to handle this yourself.

That being said, in many cases duplicating a model instance is as easy as changing it’s ID and saving.

Django Python

Update All PIP Packages

Revisiting an old Python + Django project made me realize that I needed to upgrade it’s PIP packages. Unfortunately, PIP doesn’t provide a way out of the box to update all of your installed packages at once. To update all of the PIP packages at once, use the following script.

import pip
from subprocess import call
for dist in pip.get_installed_distributions():
    call("pip install --upgrade " + dist.project_name, shell=True)

For more detail, check out this question on Stack Overflow.

Django Python

Installing Local Flavor with Django 1.5

I just started a new project using the latest release candidate of Django 1.5. One thing that I needed was the local flavor add-on so I could get a list of US states. This functionality used to be rolled into the main codebase, but it was rightfully removed in Django 1.5. To install the US local flavor package, just use PIP.

pip install

Now you should be able to import anything you need from the package in the usual manner, except from the new package instead of the old one.

from django_localflavor_us.us_states import STATE_CHOICES

For more information, check out the How To Migrate section of the local flavor docs on the Django documentation site.

Django Python

Extending Django’s Method

I’m currently working on a project where I have a model named ‘Instructor’ with a few fields:

  • first_name – CharField
  • last_name – CharField
  • departments – Many-toMany

I found out at some point that I’d really like a field called “full_name”, which is “first_name” and “last_name” concatenated together. I didn’t want to have to fill the field in though, I wanted it to happen automatically. To accomplish this, I extended Django’s method after I added the ‘full_name’ column to my model.

class Instructor(models.Model):
    first_name = models.CharField(max_length=150)
    last_name = models.CharField(max_length=150)
    departments = models.ManyToManyField(Department)
    full_name = models.CharField(max_length=180, blank=True)
    def save( self, *args, **kw ):
        self.full_name = '{0} {1}'.format( self.first_name, self.last_name )
        super( Instructor, self ).save( *args, **kw )

And that’s it! Now every time I create a new instructor with ‘first_name’ and ‘last_name’, it automatically populates the ‘full_name’ field for me.

Django Python

Deploying Django with Fabric

Fabric is a Python library and command-line tool for streamlining the use of SSH to deployment and sys-admin tasks. In the Django community Fabric has been picked up as the de facto standard for deploying apps, which is a place that it deserves. One thing I noticed though was that there wasn’t a lot of good examples for getting it to place nice with VirtualEnv.

Getting Started

The first thing you need is to make sure that you have Fabric installed.

pip install fabric

Once that’s done, open a file called and add the following imports:

from __future__ import with_statement
from fabric.api import *

Role Defs

Fabric has two functions that get used very frequently: local & run. The local() command will execute whatever you pass into in your local environment. The run() command will execute whatever you put into it in a remote environment defined in your roledefs.

A roledef defines a what a server is. For instance, if you have a nice fleshed out dev-staging-live type of environment:

evn.roledefs = {
	'dev' : [''],
	'staging' : [''],
	'live' : ['']

Once your roledefs are defined, you can run code on those specific servers by using the @roles decorator.

def ls_on_dev:
	run("ls") # Runs 'ls' on
def ls_on_staging:
	run("ls") # Runs 'ls' on

At this point, you want to run one of your new Fabric functions, from the directory where your fabfile is run:

fab ls_on_staging


Now that you’ve got a handle on the trivial examples, lets make things a little more useful. We’re going to deploy to our ‘staging’ server.

def deploy_staging(tag=False):
	code_dir = '/path/to/remote/directory'
	with cd(code_dir):
		run("git fetch")
		if tag:
			run("git checkout %s" % tag)
			run("git checkout master")
			run("git pull origin master")
		with prefix('source /path/to/virtual/environment/bin/activate'):
			run("pip install -r requirements.txt")
			run("python syncdb")
			run("python migrate")
			run("python collectstatic --noinput")
			run("touch path/to/"

All this code is pretty self-explanatory. The @roles decorator has run execute in the context of “staging”. The run commands are just regular commands you would execute at the terminal if you were manually deploying. The only potential “gotch-ya” is the with prefix call. That basically says “execute the following statements in the context of my virtual environment”. To make everthing go:

fab deploy_staging

will deploy the head of the master branch and

fab deploy_staging:tag=1.0.0

will deploy the 1.0.0 tag.


If all goes well, you can now deploy your app in seconds! If it takes longer then that, you might need to set up your ssh keys you so can login to your server without getting prompted for usernames and password.

Django Python

Deploying Django 1.4 to Heroku

Note: It is assumed that your are keeping track of your changes using Git. If you aren’t, you’ll need to be to deploy to Heroku.

If there is one thing that scares beginners away from Django, its the idea of deployment. For a PHP programmer, deployment can be as simple as FTP’ing some files to a server, and boom, deployed. This isn’t to say that PHP deployment is simple. If you have to do it from scratch (get apache running, get your db installed, get PHP installed and configured, etc, etc) it can still be very complex, but many hosting companies take care of this for you. It’s almost like you never even have to think about it, which isn’t always the case for Django. That doesn’t mean its a bad thing, just…different.

So where do we start? Heroku is as good a place as any.


Heroku is a cloud service for easy deployment of web applications. Initially it was Ruby only, but has been working hard to become a deployment service for many languages including Java, Python, and Node.js. Deploying to Heroku assumes a few things:

  1. You are familiar with Git and use it to track your code changes.
  2. You are at least passingly familiar with PostgreSQL, because that’s what you will being using. (You can use other storage devices, but PostgreSQL is the default and easiest to setup.
  3. You use PIP to manage your project’s requirements. If you aren’t doing this, you need to be. (seriously, it’s worth the effort)

Now that we have that out of the way, let’s get started. Before we can proceed further, you’ll need to get a Heroku account set up. For our testing purposes, a free account should be plenty.

  1. Go to and set up an account.
  2. Go to and download the Herok toolbelt. Follow the directions on this page up to the “login” section.

That’s all for setting up Heroku for now. Next, we’re going to move on to configure Django so it can be deployed.


Django gives you the flexibility to use almost any database under the sun. I generally develop using MySQL, but Heroku uses Postgres. As long as you haven’t been hand-tailoring queries, this shouldn’t provide any problem whatsoever. To make your project compatible with Heroku, you need to install the psycopg2 library.

pip install psycopg2

Now that you have the Postgres library installed, when your app is pushed to Heroku, Heroku will append some code to the end of your file that will point your install to the correct database.

Speaking of, you’ll also need to get your template and media paths set up correctly. To do that, add the following to the top of your and then set your paths to look like this:

import os.path
root = os.path.dirname(__file__).replace('\\','/')
MEDIA_ROOT = root + '/../media/'
STATIC_ROOT = root + '/../static/'
    root +'/../templates',

We use this calculate root variable because it’s kind of a pain to know the path of your install on Heroku. This way it doesn’t matter where you deploy your app to, it should just work. Another thing to consider is static files. Heroku can be made to serve them, but having the same domain that is serving your site serve your static files is bad practice.

Wrapping it up

Now that Django is configured for Heroku deployment, all that’s left is to deploy it! The first thing we need to do is create a requirements file so that Heroku knows what packages to install. At the top level of your project, run the following:

pip freeze > requirements.txt

Great, now if you look at the generated file you can see what software Heroku is going to install for you. Next up, we’re going to create an app on Heroku (assuming you set up the Heroku tool belt correctly). In the top level directory of your project, run the following.

heroku create --stack cedar

This added your new Heroku app as a remote on your local Git repository. All you do to deploy is:

git push heroku master

Which should give you some output that looks like:

Counting objects: 10, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (10/10), 3.59 KiB, done.
Total 10 (delta 0), reused 0 (delta 0)

-----> Heroku receiving push
-----> Python/Django app detected
-----> Preparing Python interpreter (2.7.2)
-----> Creating Virtualenv version 1.7
       New python executable in .heroku/venv/bin/python2.7
       Also creating executable in .heroku/venv/bin/python
       Installing distribute........done.
       Installing pip...............done.
       Running virtualenv with interpreter /usr/local/bin/python2.7
-----> Activating virtualenv
-----> Installing dependencies using Pip version 1.0.2
       Downloading/unpacking Django==1.4 (from -r requirements.txt (line 1))
       Successfully installed Django psycopg2
       Cleaning up...
-----> Injecting Django settings...
       Injecting code into ./hellodjango/ to read from DATABASE_URL
-----> Discovering process types
       Procfile declares types         -> (none)
       Default types for Python/Django -> web
-----> Compiled slug size is 9.3MB
-----> Launching... done, v4 deployed to Heroku

* [new branch]      master -> master

On the line immediately after “—–> Launching… done,…”, the url of your project is displayed. Before you go to it though, you need to run syncdb on Heroku. The Heroku toolbelt makes this pretty easy:

heroku run python syncdb


That’s all there is to it. If you get stuck, feel free to leave a comment. Heroku also has a great guide for getting up and running and explains some more features of the Heroku tool belt. That can be found here.

Django Python

Up and Running with Django 1.4

As with any new web framework, getting started can seem daunting. Even though Django has some of best documentation of any framework, it can still be a pain to figure out how things work. The goal of this post is to help you, the Django newcomer, get up an running with a simple blog.

Step 1: Your Environment

One thing that isn’t clearly stated in most tutorials is that how you set up your environment can either make or break your Django experience. To make your Django experience as easy as possible, you’ll need to make sure that you have two packages installed: virtualenv and virtualenvwrapper
Virtualenv can be installed using pip, and virtualenvwrapper can be installed by following the instructions on it’s site. Once you have both of these installed, you’re going to create something called a virtual environment. A virtual environment allows you to install any packages you need for your Django development without having it interfere with the rest of your system. It also allows you to create a requirements file, which allows other people to replicate your environment. To get started, we use the mkvirtualenv command.

mkvirtualenv myblog

If you at some point close your terminal window and want to load your virtual environment again you can use the workon command.

workon myblog

If by chance you don’t want to work on this environment any more, you use the deactivate command.


So bringing it all together, we’re going to create an environment, create a directory to play around in, and then install django.

cd ~/Desktop
mkvirtualenv myblog
mkdir blog
pip install django

Step 2: Create a Django Project

Now that we have our environment set up we need to create our first project. We’re going to call it “blog”.

cd blog startproject blog .

If you look in the blog directory now, you’ll see two things: a folder named blog and a file named The file is used to administer your project. Using it you’ll sync model changes, run the server, and collect static assets. So why don’t we try running the server?

chmod +x
./ runserver

The first line allows the file to be executed, and the second line starts the server. Once the second line is executed you should see the following:

(myblog)jack@jack-HP-HDX-16-Notebook-PC:~/Desktop/blog$ chmod +x
(myblog)jack@jack-HP-HDX-16-Notebook-PC:~/Desktop/blog$ ./ runserver
Validating models...

0 errors found
Django version 1.4, using settings 'blog.settings'
Development server is running at
Quit the server with CONTROL-C.

Once your development server is running, any changes you make to your files will be noticed and served automatically. If you check out the address that the server is running at, you should see this:

Step 3: Configuring a database

If we’re going to create a blog, we need to be able to store information. To do that, and database is required. In the newly create blog folder, there is a file called That file is where we configure our server and add any apps we create. First things first though, we need a database. The Django ORM does a great job of abstracting out the database layer for us, so we can plug in basically any database that we want. For the sake of simplicity, we’re going to use SQLite. To create a SQLite database, make sure that you have the SQLite3 package installed on your operating system. Make sure you are in the same folder as the file, and then execute the following commands:

sqlite3 blog.db
sqlite> .tables #Look ma, no tables in here!
sqlite> .q #quit

Now that you have a database configured, you can crack open the file and change this bit of code:

    'default': {
        'ENGINE': 'django.db.backends.',
        'NAME': '',
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',

to this:

    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'blog.db',
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',

Now that your Django project knows about your database, you need to have it create some tables for you. Go back to the directory with in it and run:

./ syncdb

Once you run syncdb, you’ll get some output that looks like this:

./ syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (leave blank to use 'jack'): 
E-mail address:
Password (again): 
Superuser created successfully.
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)

Step 4: The Posts App

A Django powered website consists of many smaller “apps”. For instance, a blog may have a posts app and a photo app. The idea is that things that aren’t concerned with each other (photos,posts) should be separate entities. For our blog projects we’re going to only use one app, and we’ll call it posts.
Creating an app is easy. As usual, Django does most of the work for you so you don’t get bogged down writing a bunch of tedious boilerplate code. Navigate back to the top of your Django project (the directory with in it) and do the following:

./ startapp posts

If you check out your project now, you’ll see a new directory called posts. If you descend into that directory, you’ll see 4 files.

  • Let’s Python know that this directory is a package. This has more uses, but it’s beyond the scope of this post.
  • We define how our models (tables) should look and act.
  • This is where we grab data from out model, massage it to our needs, and then render it to a template.
  • Unit tests go here.

Just because the app is created, doesn’t mean that Django recognizes it. You actually have to add the app to the INSTALLED_APPS section of the file. To do that, add a line to the end of the INSTALLED_APPS list.

'posts', # Don't forget the trailing comma!

Step 5: The Post Model

We’re finally to the part where we get to write code! But before we dive in, we need to think about what a blog post actually is. It will generally contain content, a title, and posted on date. With that in mind, open posts/ in your editor and add the following:

class Post(models.Model):
	title = models.CharField(max_length=100)
	content = models.TextField()
	post_date = models.DateTimeField(auto_now=True)

Once you’ve added those, save the file and then go back to and run syncdb. You should get some output that looks like:

./ syncdb
Creating tables ...
Creating table posts_post
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)

If we hadn’t added the posts app to our file, the syncdb command wouldn’t have generated our table for us.

Step 5: The Admin

One of the best parts about Django is it’s free admin interface that you get. The admin isn’t enabled by, but it’s pretty easy to set up. First off, we need to open and uncomment two lines.

    # Uncomment the next line to enable the admin:
    # Uncomment the next line to enable admin documentation:

As the comments say, uncomment the lines that say “django.contrib.admin” and “django.contrib.admindocs”. The admindocs line isn’t necessary, but it’s nice for completeness. The second step is to set up the url configuration for the admin. Go to your file and make it look like this:

from django.conf.urls import patterns, include, url
from django.contrib import admin
urlpatterns = patterns('',
    url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
    url(r'^admin/', include(,

Now that the admin is enabled, we need to add our model to it. In the blog app folder (same folder as, create a file called and put the following in it:

from posts.models import Post
from django.contrib import admin

All this does is let the admin know that it can manage your model for you. Since you technically added a new app (the admin app), you’ll need to run syncdb again.

./ syncdb
Creating tables ...
Creating table django_admin_log
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)

Go ahead an start the server again, and go to the admin. It should be located at You’ll be presented with a login screen, with which you’ll use the credentials you entered in the initial setup. Once you’re logged in, you’ll see this:

Now that you can see the Posts model in the admin, click the “add” button next to it. When you do, you’ll see a form like this.

Enter a title and some content, and then click “Save and Add Another”. Enter another title a and some content, and then click “Save”. You’ll be presented with a screen with two entries on it, that both say “Post object”.

Now, “Post object” doesn’t do a very good job of describing your post. What if you want to edit it? You won’t know what is in each post until you click into it. To fix that, go to and modify your Post model to look like this:

class Post(models.Model):
	title = models.CharField(max_length=100)
	content = models.TextField()
	post_date = models.DateTimeField(auto_now=True)
	def __unicode__(self):
		return self.title

Now when you view your post list, you’ll see the post titles instead of “Post object”.

Step 6: URLconfs

We now have a few posts in the database and can edit them in the Django admin. The next step is to set up our url structure that will allow users to view the posts on the front end of the site. Open and add the lines to it that have the “#Added” comment at the end of them.

from django.conf.urls import patterns, include, url
from django.contrib import admin
from posts.views import * #added
urlpatterns = patterns('',
    ('^$', home), #added
    (r'^post/(?P<post_id>\d+)/$',post_specific), #added
    url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
    url(r'^admin/', include(,

The first line added tells Python about your views (we’ll get to them next). The 2nd and 3rd lines added specify how certain urls are handled. The 2nd added line defines your home URLconf, and the 3rd added line defined your route for specific posts. Next, open yours posts/ file and add the following:

from django.shortcuts import render_to_response
from django.http import Http404
from posts.models import Post
def home(request):
	return render_to_response("home.html",{
		"posts" : Post.objects.all().order_by('post_date')
def post_specific(request, post_id):
		p = Post.objects.get(pk=post_id)
		raise Http404
	return render_to_response("post_specific.html",{
		"post" : p

In the first few lines we import some things we’ll need:

  • The ability to raise a 404 error.
  • Our Post model
  • A shortcut for rendering templates

The two functions we created are pretty straight forward. The home function takes all of the posts, and sends them to the “home.html” template where they will be rendered. The post_specific function checks to see if the post id that is passed in exists. If it does, it grabs that post and sends it on to the template. If it doesn’t, it raises a 404 error. Now, we need to make those templates.

Step 7: Templates

Creating templates is honestly the easiest part of the whole process. In your file, there is a variable called TEMPLATE_DIRS. You need to add the path to your templates folder in there. For instance, I created a folder called “templates” at the top level of my Django app, so mine looks like:


Now in your templates directory, create home.html and post_specific.html. In home.html put the following:

		<title>All posts!</title>
			{% for p in posts %}
			<li><a href='/post/{{ }}'>{{ p.title }}</a></li>
			{% endfor %}

and in post_specific.html put:

		<title>{{ post.title }}</title>
		{{ post.content }}
		<p />
		<a href='/'>Back</a>

Once everything is saved, go to and check out your (simple) blog!

Next Steps

This is a very simplified tutorial. The goal is to help someone get started with something easy without getting bogged down in details. One of the greatest things about Django though is that the more details you learn, the greater it gets. With that in mind, I highly suggest checking out the following sites for more learning. Good luck!

  1. – The official Django documentation. Django has some of the best documentation out of any open source project, so don’t be scared of diving in. Be sure to check out the 4 part tutorial It covers some of the same things I did, but in much greater detail.
  2. – A lot of the material in the DjangoBook website is out of date, but it does a great job explaining some key concepts that are still relevant.
  3. – The Django sub-Reddit is a great place to keep up with Django news and conversations.
  4. – A great piece on getting Django up and running on Mountain Lion

Fixing DreamHost’s Django Deployment Script

I recently created a trivial site locally with Django that I wanted to deploy on my DreamHost shared server.  DreamHost has made this process pretty painless by creating an easy-to-follow guide that can be found here.  The only problem is that it doesn’t work.  After entering in my project name and database info, i got the error message:

Creating project framework…  oops, django-admin failed to run!

With nothing to lose (and not wanting to figure out how to get Passenger set up on my own), I dove into their script.  As it turns out, the problem is on line 126.

if os.spawnl(os.P_WAIT, "/usr/bin/", "", "startproject", projname) != 0:

Apparently on DreamHost, has dropped the extension. So if you replace line 126 with the following, everything works great.

if os.spawnl(os.P_WAIT, "/usr/bin/django-admin", "django-admin", "startproject", projname) != 0: