…or how added value gets smaller.
I run ActiveState’s ActivePython on this ‘ere XP laptop. It’s quite a nice package, has the documentation in a nice indexed Windows help format, works under cygwin, etc, etc. And here Python 2.3.4 comes out. Now, call me picky, paranoid or just plain pedantic, but I like to keep all the Python installations on the three main machines I work on in sync. That’s the XP laptop, the Linux server at work and the Linux gateway/server at home. I’ve had annoying little issues in the past when using Python 2 under Windows/cygwin to develop locally and then moving to an older Python on Linux. RedHat used 1.5.2 for a lot of their setup scripts and it took me a while to bite the bullet, blow away the RPM and go for a proper Python 2 install (with all the files dropped into the same locations as the older Python, natch).
So on Linux it’s the same ole wget / tar / cd / configure / make dance as it ever was, subject to remembering exactly what set of exotic configure options I used last time (hint to self, never delete config.status). But on Windows, ActiveState are now a couple of Python releases behind, so what do I do? Of course, I can download the Windows release from python.org, but then I need to think – what will I lose by replacing ActiveState?
The considerations are – what added value have ActiveState given me in their own distribution? And have they, by providing me with an ever-so-convenient one-click .msi file, locked me into using them from now on? Hmm… this is not such a clear tradeoff as I thought.
As it happens, the Python.org installation picks up the right install directory and neatly replaces the ActiveState stuff anyway, so it’s not that key a question. But for a moment there…