(No, this isn’t one of those New Year memes; it’s just a bit of a verbal ramble).

I wanted to get an app up-and-running on WebFaction. And, for reasons not necessarily entirely connected with reality and hard requirements, I decided to go for Python3. WF offers CherryPy 3.2 against Python 3.1 but — again, for no very good reason — I decided I wanted the very latest.

So: download cherrypy.latest.tgz and python.latest.tgz. Dum de dum, configure –prefix=$HOME && make && make install. Bit of fiddling about with WF’s cherrypy setup and… we have a problem. The cherrypy engine is, for some reason of its own, using threading._Timer rather than threading.Timer and it’s not there any more in Python 3.3.

Investigation shows that this was fixed in cherrypy a few months ago. Meanwhile things will probably go ok with Python 3.2. What to do? I decided on backtracking on Python (truth be told, I hadn’t checked the cherrypy logs at this point). Download python.32.tgz. Dum de dum… and… error with _posixsubprocess. Looks like it’s fixed in the 3.2 branch but not yet released.

I’m now in the situation where I’ll either have to use a hg checkout of cherrypy or an hg checkout of Python. Or both.

Lest this be seen as a dig at either the cherrypy or the Python guys, it’s certainly not. I’m grateful to them both for the work they’ve done and for the open source infrastructure they use which gives me the information and options I’ve outlined above. I could most certainly backtrack a couple of published versions of either perfectly well for my own needs.

It’s more of an endorsement of what open source offers you if you want (and I haven’t even talked about the fact that I could fork cherrypy or Python if I needed and still maintain a version in sync with the canonical one for my own use on WF).

All I need to do now is clone hg.python.org/cpython, config & make and I’m away.