Python packaging mishegas

Sunday 29 November 2009This is over 13 years old. Be careful.

Everyone likes to complain about Python packaging, me included. It’s no fun, and it’s confusing, and it seems to be in a constant state of flux, and the languages and the distros can’t agree on who’s in charge, etc, etc.

I’ll add just one small observation: setuptools is widely used as a way to install Python packages. Look at its latest version: 0.6c11. In case it’s not familiar to you, that “c” in there means this is the eleventh release candidate for version 0.6. What!? Do we really believe that a release engineer is closely monitoring the health of this package, and is about to release 0.6, but needs this code tried first? And that this is their eleventh attempt at building an acceptable 0.6 kit?

This is crazy. According to PyPI, the first release candidate of 0.6 was posted 3 years 4 months ago, and the first beta was posted 14 months before that. What are we waiting for? Considering how widely adopted this package is, and how dependent we are on it working properly, and how little it has changed, this latest code should have just been called 1.1.

I’ve long held that it’s a plague on open source that so many project insist on staying in the zeros. But setuptools takes it even further than most with this insane charade that somehow these are release candidates.

It’s just one more small reason I say, Welcome to Distribute.


I completely agree with you about package versions, Ned! With my packages, I prefer to get a few core features working and then release 1.0, and add additional features starting from there. To me, the "1." means "Yes, I intend you to download and use this", and far too many good packages are not willing to take that step. We have almost let that first number atrophy into a meaningless placeholder; take a look at the post by Jean-Paul Calderone that's just hit Planet Python! Here:
OpenVPN wins the RC abuse contest: they released rc22 ten days ago, over three years after rc1!
I think this mostly reflects a reluctance to commit to supporting the software. This has, I agree, been a plague in the open source world for a long time (I pointed it out in Python Web Programming eight years ago, and if anything the situation has worsened since then).

Considering the amount of usage setuptools has had (and the convenience it has provided to Python users all over the world for years) the current version should be 1.x and we should be thinking about distribute as a potential alternative to setuptools 2.0.

Unfortunately most people in the open source world think that "marketing" is a dirty word, and don't seem to realize that perception becomes reality. Those outside can look at our version numbers and condemn most of open source out of hand as not ready for prime time.
The problem with Setuptools is deeper, if you look at its commit activity in the past 2 years, its very close to zero. And its maintainer is artificially maintaining the project alive through Mailing Lists, and small pre-releases, where we need more. He's not willing to open his code to more maintainers, fine. So everyone should switch to Distribute and support a community-driven effort.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.