Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

Post reply on HN
Print view View original

51–60 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#51

Post by acqq »

vidarh wrote: post #30
acqq wrote: post #15

Earlier quoted context omitted.

I'd very much like to know why it wasn't easier for him to simply write a Python code that doesn't use anything not existing in 2.4. Just because he downloaded to his computer whatever later version he likes he can't expect from all distros and all users to have exactly the same version across of all the currently running computers, it's more than unrealistic, it's simply impossible and always will be.

That doesn't solve his second issue, though, of user not wanting to touch something that depends on Python. Rewriting in C fixed both.

The config file written in the subset of Python, the only thing users would have to touch, hasn't changed! (edit: see http://news.ycombinator.com/item?id=1712269) He just changed how the file is processed, by implementing in C what would be certainly easier to implement in Python 2.4, (edit: 2.2) the lowest version he mentions.

If he insisted that users install Python 3.1 only to run his config script and they complained, I don't blame them. If he had users that haven't had Python at all, then I fully understand what he did. But then he can't blame distros and users for not having the latest and greatest Python version, it's just about the existence of Python on the target platform.

Re: Mongrel2 Says, "Goodbye Python"

#52

Post by nailer »

dagw wrote: post #24
nailer wrote: post #16

Earlier quoted context omitted.

Firstly: no hoops are required to install any version of python or any required Python module your app needs: * Just use pip and virtualenv. * Your OS remains intact, and you get better deployment for free! Replacing a component of your OS (Python 2.x) with another one (python 2.x +1 ) affects: * The OS installer (Anaconda on RHEL, Ubuntu'sequivalent) * The packaging system (yum) * Many GNOME system admin apps. * The…

My point is that /usr/bin/python probably shouldn't be a core OS component. /usr/bin/python should be whatever I want it to be. The core OS-component should be something like /sys/bin/centos-python which I will never directly use, touch or even necessarily know about. The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating th…

because, as the other poster mentions, /usr/bin has been a place for non-essential (not required by the machine to boot) software for thirty five years.

Re: Mongrel2 Says, "Goodbye Python"

#53

Post by Confusion »

rbanffy wrote: post #41

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…

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?

Re: Mongrel2 Says, "Goodbye Python"

#54

Post by dagw »

munchhausen wrote: post #36
dagw wrote: post #24

Earlier quoted context omitted.

My point is that /usr/bin/python probably shouldn't be a core OS component. /usr/bin/python should be whatever I want it to be. The core OS-component should be something like /sys/bin/centos-python which I will never directly use, touch or even necessarily know about. The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating th…

> /usr/bin/python should be whatever I want it to be. Why /usr/bin/python? /usr/bin/ has been for ages the "system" area - why would you want to suddenly usurp it for yourself? /usr/local/bin/python will on most Linux systems be executed ahead of /usr/bin/python, because /usr/local/bin/ usually precedes /usr/bin/ on the $PATH. Thus you can have your cake and eat it too. > The bottom line I guess is that mixing core O…

OS package-management (which can be considered "system" I guess)

This is where I and the distro makers disagree. When I use synaptic to install the latest version of foobar, that is not in anyway "system" and foobar should not be dumped in the same directory as core system binaries. There should be a directory that contains everything core to the OS (like python 2.4), which was only updated by the OS updater routine (which should be different from the update all the software I've installed routine). Then there should be a directory which contains everything I've chosen to install (like python 2.7) which is where everything that I install via whatever is the normal way to install things on that OS ends up. I don't care too much about what these directories are called, but having them be the same, as it is now, is not an ideal solution in my mind.

Re: Mongrel2 Says, "Goodbye Python"

#55

Post by ubernostrum »

acqq wrote: post #40
ubernostrum wrote: post #27

Earlier quoted context omitted.

I'd very much like to know why it wasn't easier for him to simply write a Python code that doesn't use anything not existing in 2.4. This isn't an "oh, a brand-new version just now came out and it's not in the distros yet" problem. Python 2.4 is six years out of date at this point. Python 2.3, which Red Hat will support until 2012, is even older (and for the longest time Red Hat didn't even use a 2.x Python at all --…

Why is it "simply unacceptable" to produce the code to the least common denominator? Anything that is successful must have more versions in the installed base. You can target a single version of something only if it's not used at all. It seems too much developers live in "Everybody must have that what I have" world. I haven't tried myself, but I can't believe Python changed that much that you can't write the plain Py…

You can write code that runs on 2.4, yes. But you miss quite a few useful features of more recent Pythons by doing so (context managers, for example, are a big deal, as are several of the newer standard-library modules). The same thing used to happen with Python 2.3; you could write 2.3-compatible code, but it meant no decorators, no generators, etc.

Python has these useful features and has had them for years; why is it acceptable to say that it will be 5-10 years before we can reliably use anything new?

Re: Mongrel2 Says, "Goodbye Python"

#56

Post by terra_t »

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 beginning of scripts so that they work correctly.

Re: Mongrel2 Says, "Goodbye Python"

#57

Post by JeffJenkins »

cdavid wrote: post #14
nailer wrote: post #7

I understand what Zed's saying here - particularly as I came to programming from a sys admin background. Just like Perl before it, Python (and to some extent, Ruby if you use Puppet) are part of the OS (Linux OS or OS X that is). Shit can and will break if you mess with your OS. You never got this with PHP because people didn't use it in their OSs. But there's a simple solution: not only does the Ministry of Packagin…

I am curious: how do you think virtualenv and pip would solve the issue of antiquated python ? The only thing that virtualenv does is to install packages in some temporary location, that you can throw away later without impacting anything outside python. Virtualenv does nothing to solve those issues. I am actually wondering whether it does not even aggravates them because people think those tools magically solve back…

It creates an entirely independent python installation, including executable. Of course, you need to install that executable somewhere before you can create an independent copy of it, but there's a decent chance you'll be able to do that even as a normal user in your home directory.

Re: Mongrel2 Says, "Goodbye Python"

#58

Post by timclark »

rbanffy wrote: post #41

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…

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.

Re: Mongrel2 Says, "Goodbye Python"

#59

Post by [deleted] »

nailer wrote: post #7

I understand what Zed's saying here - particularly as I came to programming from a sys admin background. Just like Perl before it, Python (and to some extent, Ruby if you use Puppet) are part of the OS (Linux OS or OS X that is). Shit can and will break if you mess with your OS. You never got this with PHP because people didn't use it in their OSs. But there's a simple solution: not only does the Ministry of Packagin…

[deleted]

Re: Mongrel2 Says, "Goodbye Python"

#60

Post by cookiecaper »

nailer wrote: post #7

I understand what Zed's saying here - particularly as I came to programming from a sys admin background. Just like Perl before it, Python (and to some extent, Ruby if you use Puppet) are part of the OS (Linux OS or OS X that is). Shit can and will break if you mess with your OS. You never got this with PHP because people didn't use it in their OSs. But there's a simple solution: not only does the Ministry of Packagin…

Strong agree, virtualenv is a pre-requisite. We are running 2.6 in a venv on CentOS and it works fine and doesn't interfere with anything from the distro that relies on system Python.

This is really the better approach anyway because if you get another project that requires conflicting library versions with your last project, it's a simple thing. It also makes it easy to take your project across servers, just make another venv (usually pretty fast to get going) or use the portability flags and take the venv with you.

I don't see much point in trying to make everything play nicely with system Python when you're doing real work, but it would be nice if the distros would start keeping normal system Python up and distribute virtualenvs for their stupid broken old crap that they won't update.

Post reply on HN