Installed apps in Django - what about versions?

Question

After looking at the reusable apps chapter of Practical Django Projects and listening to the DjangoCon (Pycon?) lecture, there seems to be an emphasis on making your apps pluggable by installing them into the Python path, namely site-packages.

What I don't understand is what happens when the version of one of those installed apps changes. If I update one of the apps that's installed to site-packages, then won't that break all my current projects that use it? I never noticed anything in settings.py that let's you specify the version of the app you're importing.

I think in Ruby/Rails, they're able to freeze gems for this sort of situation. But what are we supposed to do in Python/Django?

Answer 1

Having multiple versions of the same package gets messy (setuptools can do it, though).

I've found it cleaner to put each project in its own virtualenv. We use virtualevwrapper to manage the virtualenvs easily, and the --no-site-packages option to make every project really self-contained and portable across machines.

This is the recommended setup for mod_wsgi servers.

Answer 2

You definitely don't want to put your Django apps into site-packages if you have more than one Django site.

The best way, as Ken Arnold answered, is to use Ian Bicking's virtualenv (Virtual Python Environment Builder). This is especially true if you have to run multiple versions of Django.

However, if you can run a single version of Python and Django then it might be a little easier to just install the apps into your project directory. This way if an external app gets updated you can upgrade each of your projects one at a time as you see fit. This is the structure Pinax used for external Django apps at one time, but I think it's using virtualenv + pip (instead of setuptools/distutils) now.

Answer 3

What we do.

We put only "3rd-party" stuff in site-packages. Django, XLRD, PIL, etc.

We keep our overall project structured as a collection of packages and Django projects. Each project is a portion of the overall site. We have two separate behaviors for port 80 and port 443 (SSL).

OverallProject/

    aPackage/
    anotherPackage/

    djangoProject80/
        settings.py
        logging.ini
        app_a_1/
            models.py # app a, version 1 schema
        app_a_2/
            models.py # app a, version 2 schema
        app_b_2/
            models.py
        app_c_1/
            models.py

    djangoProject443/

    test/
    tool/

We use a version number as part of the app name. This is the major version number, and is tied to the schema, since "uses-the-same-schema" is one definition of major release compatibility.

You have to migrated the data and prove that things work in the new version. Then you can delete the old version and remove the schema from the database. Migrating the data is challenging because you can't run both apps side-by-side.

Most applications have just one current version installed.