My point is that the lowest common denominator is higher for users of something like Django because Python is a central component of what they do, thus it's reasonable to assume that they are not using an 8-year old Python environment.
Tell that to the many, many people I know who are using Django on RHEL. There's a reason why we just (as of Django 1.2) got around to dropping Python 2.3 support...
We can't drop Python 2.3 until 2012 (when RHEL4 reaches end-of-life).
In the ancient days, stuff the OS relied on was in /usr/sbin and stuff that was "yours" was in /usr/local/bin (or /opt) and stuff that no-one was quite sure whose it was was in /usr/bin. And lo, peace and harmony did reign upon the face of Unix. And the sysadmin did lie down with the developer, and it was good. Who even knows how it works these days?
If there is one thing that ticks me off about modern unix it is that to install I end up having to install / upgrade half the rest of the system because of all the interdependencies between packages.
I think that's more symptomatic of the open source culture around most Unix systems than Unix itself.
Being able to share and depend on other people's libraries is great for the developers as long as they're not tied to providing support for when users can't compile or run their software.
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…
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.
This thread is a classic example of something that happens over and over. Someone says something is hard to use. 1/3 of the responses agree. 1/3 of the responses disagree, say it's simple. 1/3 of the responses say it's simple, all you have to do is use additional software package Y to manage X and it works great. This is usually a sign that there is some merit to the original assertion.
We're talking about technology, not politics so consensus be damned. There is a fact of the matter independent of perception and lack of consensus in and of itself is not a valid attack on a position. In this case maybe we can listen to those who claim the python situation isn't that bad and have provided specific technical solutions for evaluation.
If the question is "Do a significant number of users run into problems with a piece of software," then the consensus is absolutely relevant.
FYI - Fedora 13 shipped with Python 2.6, Fedora 14 is going to ship with Python 2.7 and 3.1 in parallel. Not every distribution ships ancient versions. I also recommend using virtualenv and pip, these tools make it much easier to create an easily reproducable Python environment.
True, but I have had no end of problems using Python apps on Fedora. I now pretty much kill the packages straight away and reinstall from source.
We're talking about technology, not politics so consensus be damned. There is a fact of the matter independent of perception and lack of consensus in and of itself is not a valid attack on a position. In this case maybe we can listen to those who claim the python situation isn't that bad and have provided specific technical solutions for evaluation.
If the question is "Do a significant number of users run into problems with a piece of software," then the consensus is absolutely relevant.
The question isn't whether there is a problem but whether there is a solution. The virtualenv/pip people seem to think so.
Some flavour of Debian would be my preference. Generally with Python WSGI applications I tend to keep things sandboxed using virtualenv and pip in any case.
I am complete newbie when it comes to running a server but have a bit of experience using Ubuntu in my local box. Is ubuntu a good choice? Since most use a flavor of Red Hat like CentOS I am a bit hesitant to use Ubuntu in production.
It depends on what you are using the server for and who is using the server.
Ubuntu and debian are used by plenty of people in production and are probably the better choice for learning how to set up a server if you already use ubuntu.
This is an insane idea. I should not have to have a whole other version of python just to run a language independent web server. The choice Zed made is a great choice--all the functionality of the original python m2sh is present in the new, and there's nothing external to support, or dump somewhere else.
It's not that crazy. Python is designed for embedding. The interpreter is small. Commercial software that depends on Python (almost) always embeds it.
I know this, however, Zed was using this for a shell command, not as an embedded scripting language.
This is a complete non-issue. ActiveState for example installs Python, Tcl, etc in /opt.
Except no one installs ActiveState. For most, most of the market, the RedHat supplied version of python is python.
Does RedHat still have that much of a market share in linux to demand such? I guess I am out of the loop, but I hear way more about ubuntu these days than RedHat...
Python brought this on itself by having no respect for compatibility between versions. There's really no such thing as the Python language, only "Python 2.2", "Python 2.4", "Python 3". If you want to run Python scripts, you need to have three or four different Python runtimes installed, and that's asking a lot of both the distros and of users who need to keep everything straight, and probably even hack the #! at the…
When you add features as useful as set() datatypes, if-else expressions, generators, and comprehensions, people are going to use them. Python 2.2 code nearly always runs without modification on Python 2.3+ (the only exception would be collisions between variable names and new keywords). But someone targeting Python 2.6 has a huge hassle when deploying to older versions. This means that Python is actually adding useful new functionality; that is, the incompatibility is a symptom of a good thing.