Using Python Packages – An Overview

Yesterday I gave a presentation at PyCologne about Python packages. It was meant as a kind of sequel to the “Cooking Eggs” talk given by Christopher Arndt (in German) in September. While he presented ways to create Python packages, I focused on how to use Python packages.

Python comes with batteries included, but sometimes, battery power is not enough. Thankfully, there are countless packages available for use. Given that there “should be one– and preferably only one –obvious way to do it,” using Python packages can be quite intimidating. The documentation of your package might say to download, unzip und run python setup.py install. Meet distutils. Or just do easy_install MyPackage, which is uses setuptools. But then you hear that setuptools is superseeded by distribute and instead of easy_install, you should use pip. And then there is virtualenv, which is awesome, but can be even more awesome with virtualenvwrapper. What a mess!

My conclusion: use distribute, pip, virtualenv and virtualenvwrapper.

You can download the slides or view them with Slideshare:

Slides from EuroDjangoCon

These are the slides and code of talks given at the EuroDjangoCon, which is held in Prague from May 4th to May 6th. This information can also be found in the EuroDjangoCon Wiki.

Day 1:

Day 2:

Day 3:

Other:

This post will be updated over time. Please leave a comment if you think something is missing.

Building a site with Django? Start with Pinax!

Some time ago, I watched James Tauber’s talk at DjangoCon about Pinax, a collection of re-usable Django applications. If you are thinking of a collection as a bunch of apps carelessly thrown together, you could not be more mistaken. Pinax is the foundation for a complete social networking site which covers most features you can imagine, the whole nine yards.

Forget django-admin.py startproject! Just do cp pinax myproject, remove some stuff you don’t need, adjust the templates and you are done!

Ok, I might be exagerating a bit, but watch the talk to build your own opinion.

Pitfalls in Django unittests

I’m currently rewriting dwidder [1] and I just spent way to much time on a unit test for the registration view. These are the things that made me stumble:

  1. Write fixtures. Unit tests run on an empty database. Somewhere deep in your code might be a reference to one of the default applications, like django.contrib.sites, which will fail, because there is no default site object in your database.
  2. Don’t subclass unittest.TestCase. Use Django’s TestCase class instead. Otherwise you will miss all the fancy stuff, like automatic fixture loading.
  3. Import mail, not outbox. Django provides a dummy email outbox. But to make it work as expected, you have to import the mail module. If you import the outbox directly, it will always be empty.

[1] a now defunct site where you could tweet by sending an SMS to a German mobile phone number