It's funny how, for Zed, anything that doesn't work the way he thinks it's supposed to work is "broken" and the result of some boneheaded decision and that it "sucks".
I too am frustrated by ancient versions of server OSs that use equally ancient versions of Python, but that's why virtualenv was invented. And source distributions. I am happy using it when required.
Being "stable" in OS terms is not changing APIs very often. One of the good things is that I know that code I wrote for RHEL 4 the day it was launched will run flawlessly on RHEL 4 today. The primary goal of such a Linux distro is that "it has to work". I won't touch the system parts.
He doesn't blame it on 'some boneheaded decision'. As far as I can see, he doesn't blame anyone, he just notes the current state of affairs, in which the situation is indeed pretty much broken. Not just for him, because he is far from the only one that thinks it should work a certain way.
that's why virtualenv was invented
Yes and shouldn't it also be the OSes that use it to isolate their default Python install?
It's a design decision. They have a default Python install they support, validate and keep working that you shouldn't mess with. I am pretty sure you can't ruin a RHEL just by installing RPMs from RH's repos. If the Python the OS vendor provides is somewhat inadequate to you, it's your job to provide another one or to use another distro. However, if you choose to write your code against the distro's Python (something that's not that hard, really - 2.4 is a modern language) you can rest assured your code will work for as long as the distro is supported. It's not "broken", not a boneheaded decision. It's just the way it is.
If you require 2.7 or 3.x goodness, you can always set-up different environments separate from the OS's Python and just be happy with it.
It is completely possible, easy and reasonable to have a multiple versions of python installed. Many OSes do this, and the convention is to have them named like python2.4 python2.5 and so on.
Any system scripts that require 2.4 can then change their shebang to say /usr/bin/python2.4. At the very same time, packages for newer pythons can be made available for ease-of-use for the rest of the world. This breaks nothing.
Actually, it's not that Python doesn't work the way I expect, it's that distros have killed Python's portability promise and made C more attractive. Granted I'm able to code C well enough to pull this off, but having to do this is annoying.
Also, this is how things improve. Someone doesn't like the current state of affairs and changes it.
Are you implying that Python is not portable between distros? I say that because I am much more familiar with Red Hat and Debian-based flavors and, on both environments, Python seems rather sane, if somehow crufty sometimes.
What specific Python dependency did the move to C cure? What are the most common complains regarding libraries and versions? Perhaps listing them can help change whatever is wrong.
It isn't Zed complaining, the 1.0 instructions used pip and suggested using virtualenv etc. It would seem he is just reacting to what his customers are telling him - namely that it is difficult getting python to work on their systems and they don't want to play around with pip and virtualenv.
An end-user of an application doesn't want to fiddle around with library management tools.
It's a shame he felt he had to tear out Python. I understand the pain of relying on distro-supported Python. You basically have to target 2.3 at minimum if you want to distribute an application. If you have windows users, it can be even more painful.
Theoretically, couldn't you have configure check your setup for Python 2.x? Setup your make process to download and install the proper python in a local build environment? I'm just running off random ideas, not sure if it would be feasible.
Too late for Mongrel2 of course, but C isn't so bad either.
I think he is talking from his user's point of view. Not all of them could be proficient in various distros of Linux and their Python versions. So if something doesn't work for them, it means its broken.
I certainly think that anything that doesn't work the way I expect is broken and things that are broken in this way frequently suck... and that seems to be the attitude of most of the people I know.
I too am frustrated by ancient versions of server OSs that use equally ancient versions of Python, but that's why virtualenv was invented. And source distributions. I am happy using it when required.
Being "stable" in OS terms is not changing APIs very often. One of the good things is that I know that code I wrote for RHEL 4 the day it was launched will run flawlessly on RHEL 4 today. The primary goal of such a Linux distro is that "it has to work". I won't touch the system parts.