The Python/Django duet is fantastic, everyone knows that. However it can be even more awesome with these apps:

1. South

This is an intelligent schema and data migration tool. If you don’t use it yet, you will want to after reading this post. Okay… but what it is exactly?

When you create a Django app, you are using the “syncdb” command. After a model changes you have to delete the whole database and run “syncdb,” or manually do SQL changes directly in the database. It’s even more tragic when you already have production data. Not so fun, right?

Enter our hero: “South.” Its main objectives are to provide a simple, stable and database-independent migration layer to prevent all the hassles schema changes bring to your Django applications over time.

Example:

Let’s create a model in our “southtut” app:

class Knight(models.Model):
    name = models.CharField(max_length=100)
    of_the_round_table = models.BooleanField()

Then let’s create our first migration:

$ ./manage.py schemamigration southtut --initial
Creating migrations directory at '/home/andrew/Programs/litret/southtut/migrations'...
Creating __init__.py in '/home/andrew/Programs/litret/southtut/migrations'...
+ Added model southtut.Knight
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate southtut

And apply our new migration:

$ ./manage.py migrate southtut
Running migrations for southtut:
- Migrating forwards to 0001_initial.
> southtut:0001_initial
- Loading initial data for southtut.

Very similar to “syncdb,” for now. But now time for magic! Let’s modify the model:

class Knight(models.Model):
    name = models.CharField(max_length=100)
    of_the_round_table = models.BooleanField()
    dances_whenever_able = models.BooleanField()

To apply these changes we have to run these two commands:

$ ./manage.py schemamigration southtut --auto
$ ./manage.py migrate southtut

And that’s all! All data is in place with the new structure.

Read more here: http://south.aeracode.org/

2. Fabric

Fabric is the second must have app. Fabric is a Python library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.

It provides a basic suite of operations for executing local or remote shell commands (normally or via sudo) and uploading/downloading files, as well as auxiliary functionality such as prompting the running user for input, or aborting execution.

Example:

You are working on a Django app locally. After you finish working, you commit all changes to a repository. Now you want to deploy all the changes to staging or production server. This is what it normally looks like:

– open new console
– connect with server via SSH
– run virtual environment (if any)
– install any new requirements
– pull all changes from repository
– run syncdb, migrations (if South is used)
– collect static files
– delete *.pyc files (to be sure)
– restart apache/nginx or whatever server you have using
– restart memcache

10 steps and we are ready. But… how about doing same thing using only one line? Simple — use Fabric. With the proper configuration of all these steps we can close in this line:

$ fab production launch

Here you can read more: http://fabfile.org

3. Django Compressor

What we would like to achieve in our website:

– every file is downloaded from server only ONCE (every next time cache is used)
– only one CSS and JS file is downloaded
– client browser always knows what file is actual and what file should be downloaded again

All of that is possible with Django Compressor.

Django Compressor combines and compresses linked and inline Javascript or CSS in a Django template into cacheable static files by using the “compress” template tag.

Example:

{% load compress %}

{% compress css %}

{% endcompress %}

Which would be rendered all in one file:

link rel="stylesheet" href="/static/CACHE/css/optimized_file.css" type="text/css" media="screen"

More information here: https://github.com/jezdez/django_compressor

4. Tastypie

Sometimes we have to add an API to our application without the ability to modify the sources of that app. Tastypie is exactly what we need. It provides a convenient yet powerful and highly customizable abstraction for creating REST-style interfaces. It relies only on its own code and focuses on providing a REST-style API.
Let’s create a resource class for our model “Knight”:

from tastypie.resources import ModelResource
from southtut.models import Knight

class KnightResource(ModelResource):
class Meta:
queryset = Knight.objects.all()
resource_name = ‘knight’

Now we have to hook up a resource:

from django.conf.urls.defaults import *
from southtut.api import KnightResource

knight_resource = KnightResource()

urlpatterns = patterns(”,
# …
(r’^southtut/’, include(‘southtut.urls’)),
(r’^api/’, include(knight_resource.urls)),
)

And voila! We have set up our REST interface. Our resource is available at these urls:

http://127.0.0.1:8000/api/knight/?format=json
http://127.0.0.1:8000/api/knight/1/?format=json
http://127.0.0.1:8000/api/knight/schema/?format=json
etc...

Of course, this is only one simple example. For safety, Tastypie ships with the authorization class and many more.

More information: http://tastypieapi.org/

5. Easy Thumbnails

There are many apps for thumbnails. However, this one is the simplest and most powerful I’ve ever seen. We only have to add ‘easy_thumbnails’ in INSTALLED_APPS.

It’s great for quick thumbnails in template usage:

{% load thumbnail %}
{% thumbnail [source] [size] [options] %}

where:

– source must be a File object, usually an Image/FileField of a model instance,
– size in the format [width]x[height]
– list of options like sharpen, crop, and quality=90

And that’s all. The thumbnail is created dynamically (if it doesn’t exist) when the page is requested.

Of course, there is Model and Low Level usage too.

More information: https://github.com/SmileyChris/easy-thumbnails