We find using --system-site-packages on your deployment is a better solution for deploying Django - especially when it comes to dependencies that need to be compiled.
It gives you flexibility on your environment and lets you deploy onto machines without a C compiler, or strange setup requirements e.g. psycopg2 on OS X, and PIL on Ubuntu.
You then install Django, and other Python-only dependencies inside your virtualenv, which stops you polluting the global Python path.
It requires some discipline in your development setup, but it means you're able to develop across whatever platform you choose, and simplifies deployment.
What's wrong with PIL on Ubuntu? If you're running into needing to repoint JPEG_ROOT/ZLIB_ROOT - I've started avoiding that by symlinking where PIL expects things to be to where they actually are). Works a charm, and avoids using --system-site-packages.
I used to do this, but it feels like a suboptimal solution. I could use Fabric to ensure the links are there but it adds more complexity to the setup:
a) Another step to remember
b) Requires a compiler on the production system
c) Requires you to manually resolve the image library dependencies
Multiplying that across multiple packages can quicky become a headache. It's much easier to let the OS package manager deal with this, and will make your system more robust over time.
It gives you flexibility on your environment and lets you deploy onto machines without a C compiler, or strange setup requirements e.g. psycopg2 on OS X, and PIL on Ubuntu.
You then install Django, and other Python-only dependencies inside your virtualenv, which stops you polluting the global Python path.
It requires some discipline in your development setup, but it means you're able to develop across whatever platform you choose, and simplifies deployment.