But it got me wondering. What is the largest open-source Django-based project around?

Some times ago I already posted some ’source lines of code’ (SLoCs) metrics about the Peach³ Django project (41209 at the time).

But is SLoCs the best way to define which project is the largest? Or maybe we should use some more ‘Django-based’ metrics, like number of unique apps (22 for Peach³) or number of models (86)?

Or maybe the largest project is the project with the most people using it on a day-to-day basis (approximately 350 for Peach³ at the moment).

And, using any of these metrics, what would be the largest Django-based open-source project around at the moment? I could not find any metrics of any other projects.

I feel Peach³ might actually be one of the bigger projects out there, but I have nothing to base that feeling on.

For example, I used to have two models defined like this:

class Assignment(models.Model):
    course = models.ForeignKey(Course)
    name = models.CharField(max_length=100)

class AssignmentEdition(models.Model):
    assignment = models.ForeignKey(Assignment)
    # ... other fields

The way the assignments were defined, each edition of an assignment has the same name. I needed to change this into:

class Assignment(models.Model):
    course = models.ForeignKey(Course)

class AssignmentEdition(models.Model):
    assignment = models.ForeignKey(Assignment)
    name = models.CharField(max_length=100)
    # ... other fields

Each edition has it’s own name. It’s still possible for editions to have the same name, but it is also possible to have a different name and still be an edition of the same assignment.

During the migration I want each assignment edition to get the name of it’s assignment. One way to do this is to use SQL queries to get the names of the assignments and update the assignment edition names, but that’s not very Django-like. I want to use QuerySets. I solved it in the following way (this works with Django 1.0.2 and South 0.4):

from south.db import db
from django.db import models

class Assignment(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        db_table = 'assignment_assignment'
        app_label = 'assignment_migrations_0002_assignment_names'

class AssignmentEdition(models.Model):
    assignment = models.ForeignKey(Assignment)
    name = models.CharField(max_length=100)

    class Meta:
        db_table = 'assignment_assignmentedition'
        app_label = 'assignment_migrations_0002_assignment_names'

class Migration:
    def forwards(self):
        db.start_transaction()

        # Add the new name column to AssignmentEdition
        db.add_column('assignment_assignmentedition', 'name',
                      models.CharField(max_length=100))

        # Convert the existing data
        if not db.dry_run:
            db.commit_transaction()
            db.start_transaction()

            for ae in AssignmentEdition.objects.all():
                ae.name = ae.assignment.name
                ae.save()

        # Delete the name column from Assignment
        db.delete_column('assignment_assignment', 'name')

        db.commit_transaction()

    def backwards(self):
        raise NotImplementedError

First, I need to create the models as they are when I want to convert the data. I can’t rely on definitions in models.py because first of all Assignment won’t have any name defined there, and secondly a future migration might remove the name field from AssignmentEdition as well. Also I only include the fields that are needed for the conversion here, so eg. the course field in Assignment is not included.

The Meta options are required for Django to be able to find the correct database tables. The db_table meta option is the table name (as created by Django), the app_label meta option is required because Django caches it’s models, and if I were to define another AssignmentEdition in another migration, Django will use the AssignmentEdition defined here instead of the one for that migration. It uses app_label as the key for this caching, so app_label needs to be a unique label for this migration.

The rest is pretty straightforward: after adding the new name column and saving the transaction, I can loop over all existing assignment editions and update the name field using a standard Django QuerySet. After the conversion the name column in Assignment can be deleted.

After using a few other IDE’s I settled down with Eclipse with Aptana plug-in as the IDE I use for peach³ development. This one environment has support for everything I need while developing a Django application: Python, HTML and JavaScript support is great, with code completion, including completion for the Ext.js javascript library. And I even have the idea that I’m not using the full power of Eclipse yet.

By default, Eclipse and Aptana have no Python support, but it can be integrated with PyDev.

The only thing missing to make it the best environment (in my opinion) is support for Django template tags: a Django template tag inside a HTML or JavaScript file usually results in an inline error message. But you can just ignore these error messages.

For some of the most used Django management commands (runserver and test) I’ve defined ‘tools’ in the Eclipse interface and I can now start my development server or run the testsuite with a single click inside Eclipse.

Here is how I set up the single-click runserver tool:

In “Run > External Tools > External Tools…” I’ve added a new tool called “Django Runserver” and I set up the following on the Main-tab of the tool configuration:

I had to setup one more thing: without it, some of the output is lost and output on standard out and standard error won’t be in the correct order: On the Environment-tab of the tool configuration I had to add the environment variable ‘PYTHONUNBUFFERED‘ with value ‘Y’.

That’s it. Now you can click ‘Django runserver’ in the tools menu (see picture below) and the Django development server starts, with it’s output captured inside Eclipse.

I’ve set up a similar tool to run the tests and to update the development environment, for which I use buildout.

zc.buildout

Using tips in this blog posting I have set up a development environment that is seperate from my local python installation using zc.buildout. This has the advantage that I do not have to keep track of the versions of all the python packages and external Django apps I’m using, all this information is stored in the buildout configuration. A simple “bin/buildout” command suffices to setup a working environment for a local development version of peach³, and I’ve set this command up as another tool in Eclipse.

Here is snippet of my current buildout.cfg:

[buildout]
parts =
  django
  extras
eggs =
  werkzeug
  pytz
  pygments
  chardet
  docutils
  south
  python-memcached
  mysql-python

[extras]
recipe = iw.recipe.subversion
urls =
  http://django-command-extensions.googlecode.com/svn/trunk/ django-command-extensions

[django]
recipe = djangorecipe
version = 1.0.2
settings = development
project = peach3
eggs =
  ${buildout:eggs}
extra-paths =
  ${extras:location}/django-command-extensions/

This script contains everything needed to setup the right environment for the Django development server.