setuptools versioning – wtf?

Nowadays I'm taking Debian's APT software management system pretty much for granted. It probably represents the most advanced and powerful system. So I'm not instantly turned away if I find other systems that don't work as well. Observing how Windows users struggle with getting the 50 different installed pieces of software to update that all use their own mechanisms thus wasting computing time and hard disk space while often getting annoyed by "Do you want to update now?" requests or sudden reboots is fun. Anyway, as an addicted Python programmer I obviously had to deal with the "setuptools" already. It's Python's pendant to Perl's CPAN. It can download Python modules with certain versions, satisfy dependencies automatically etc. The central place for Python modules is the Python Package Index (PyPi). Obviously I usually wouldn't need to deal with the setuptools often because Debian already provides properly packages Python modules but sometimes it's nice to deploy applications within a virtualenv environment (similar to a chroot with its own set of module versions not conflicting with other versions installed on the system). Still I think that setuptools is pretty pathetic.

  • You can't uninstall modules properly. This is a no-go – we aren't in the Windows 95 ages any more.
  • PyPi often just links to the developers' home pages which tend to go offline when you urgently need to deploy an application and can't get a certain version downloaded. (Pylons has kindly collected the needed eggs on their download page for that case.)
  • Sometimes certain versions are requested that are no longer available on PyPi that have been released just weeks ago.
  • Outside of the virtualenv you'd have to install modules system-wide which collides with your software management like APT (unless you have an operating system like Windows that doesn't care anyway).

But the single most pathetic detail about setuptools is their versioning. Gustavo Noronha Silva pointed me to /usr/share/pyshared/pkg_resources.py which contained an explanation of how version numbers are compared:

Strings like "a", "b", "c", "alpha", "beta", "candidate" and so on (that come before "final" alphabetically) are assumed to be pre-release versions, so that the version "2.4" is considered newer than "2.4a1". Finally, to handle miscellaneous cases, the strings "pre", "preview", and "rc" are treated as if they were "c", i.e. as though they were release candidates, and therefore are not as new as a version string that does not contain them.

So the sorting goes something like a, b, c, pre, preview, rc, alpha, beta, candidate, final. And "2.4" is newer than "2.4a1" but not newer than "2.4f1"? Please people, lay off the drugs. I feel tempted to send that to The daily wtf. I thought that setuptools and virtualenv is a good combination if a certain Python module is not yet available in Debian. But I think I'd rather spend 30 minutes to create a proper Debian package with a real version numbering system instead of wasting my time with these antics. Don't get me wrong. I appreciate the intention of setuptools and easy_install. But the world needs a 2.0 of this work. From what I heard hardly anyone understands setuptools well enough to provide something better. Bummer.

Leave a Reply

Your email address will not be published. Required fields are marked *