Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

221–230 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#221

Earlier quoted context omitted.

Oh well, you know, it's definitely not trouble enough to drive me away from Python. Despite the whole version madness across Linux distributions, Python is still my preferred language for web development, and even if that means going through a bit of trouble getting it properly installed on a particular system, hopefully that is something I'll only have to do and document once every few years. I surely hope all distr…

It's trouble enough to drive people away from Mongrel2. Also, I find it weird that you take me saying "we ditched python in mongrel2 because of Linux" to mean "Python SUCKS! Stop using it." Never said the latter, only the former.

Sorry. Indeed.

Re: Mongrel2 Says, "Goodbye Python"

#222
post #38

I'm not sure why he concerns himself with old distros. Are they the customers for Mongrel2? The description on the website emphasizes modern web technologies. Using Rails 3 is best with Ruby 1.9.2, and yet the only popular distros that install that via their package management system are the rolling release ones, Arch Linux and Gentoo (where it is masked). Most people willing to use this brand new software are also w…

Upgrading Ruby to 1.9.2 won't break your OS. Upgrading Python on some distros can even break package management. That's the difference. And if you have a well tested, rock stable environment you generally don't want to mess with it if you don't have to, or may not easily be able to. You want to not support older than Lenny. Well, we have machines that are still on Sarge, though slowly being upgraded. Some of the mach…

I'm sure older machines are out there and are doing fine for their purpose. But are you planning to install Mongrel2 on them?

Re: Mongrel2 Says, "Goodbye Python"

#223
post #68

Earlier quoted context omitted.

CentOS is about as conservative an option as you can get, though. Unusably so, in my opinion. None of the other popular distros have packages that old.

CentOS is about as conservative an option as you can get Wait, wasn't that attribute reserved for debian/stable?

Maybe it was in the past, but these days Debian stable is fresh by comparison.

Re: Mongrel2 Says, "Goodbye Python"

#224
post #180

Earlier quoted context omitted.

Programming language popularity works like fashion, but not because developers are shallow and finicky. It's because it's actually important what other developers are using. You could have the best programming language ever, but libraries, resources, help, and advice won't exist until you have a lot of people using it. There's enough adventurous programmers to bootstrap this cycle with new languages, but the general…

I agree to an extent. That stuff matters when you're starting out and just learning. But after you get to a certain level the 'language ecosystem' isn't important at all IMHO.

Massively disagree: once I get to a certain level, there's no way in hell I want to waste my time implementing all of (java) commons-lang, or my own sqlite bindings, etc.

When the languages ecosystem is flourishing, I am productive. When it's not, I'm shaving yaks that prefer not to be shaved.

Re: Mongrel2 Says, "Goodbye Python"

#225
Every unix based OS deals with package resolution in a stupid way. Didn't the old lisp machines before Linux, FreeBSD, etc solve this with self contained state in a single object? Everything old and solved is the new and hard problem.

Re: Mongrel2 Says, "Goodbye Python"

#226
post #9

Earlier quoted context omitted.

Indeed. I got to the statement: "The distros have killed Python." Said out loud, "here we go", and settled down for some classic Zed. Can't fault him on it, though.

I'd go one further: distros in general haven't killed Python, Red Hat has. By tying their flagship OS to a six-year-old Python release, they've made it impossible for a lot of popular software to move on and take advantage of more recent advances in the language (since "screw everybody who uses Red Hat" simply isn't a viable option).

It's not reasonable to expect OS update schedules to coincide with language update schedules. Red Hat's priorities are extremely unlikely to be the same as yours. The apps I build that depend on ruby or python get deployed with a custom build of same into a separate prefix. So either dropping the python dependency or bundling python make sense for mongrel2. Maybe dropping it was easier in this case.

Re: Mongrel2 Says, "Goodbye Python"

#227
post #56

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…

Mercurial runs unchanged on 2.4 to 2.7, and it's not a trivial little piece of software. Pretty much the only thing you need to do to make your Python code run on 2.x+ is "don't use features released after 2.x".

It depends on what you mean by running unchanged. Numpy and scipy also support 2.4 to 2.7 (and soon to 3.1) from the same codebase. But everytime a new version of python is out, we need to make some changes, albeit relatively minors. So it is not perfect either.

Re: Mongrel2 Says, "Goodbye Python"

#228
post #200
post #194

Earlier quoted context omitted.

No, it's not symptomatic. The problem is that about 80% of packages in distributions could be compiled against older versions of dependencies, but never do. Be default, distributions mark in the packages the dependency of their currently installed libraries, ignoring the fact that the software could have been compiled against an older version of the library too. There's no mechanism for identifying such minimum possi…

> There's no mechanism for identifying such minimum possible dependencies. Er, yes there is, and there has been for at least the last 12 years, and probably more. Requires: python >= 2.6.1

What you mention is a manual mechanism which is not often used. Instead, developers say:

Requires: python

The automatic mechanism in place is to run ldd, identify the list of libraries used by the executables distributed, and mark those libraries as dependencies. Since the package is build on your newer, Debian 5 package, it requires (automatically) the newer libfoo (like python-2.7), while it would have worked just fine with the older libfoo (python-2.5).

Re: Mongrel2 Says, "Goodbye Python"

#229
post #194

Earlier quoted context omitted.

No, it's not symptomatic. The problem is that about 80% of packages in distributions could be compiled against older versions of dependencies, but never do. Be default, distributions mark in the packages the dependency of their currently installed libraries, ignoring the fact that the software could have been compiled against an older version of the library too. There's no mechanism for identifying such minimum possi…

Not sure that's true, most packaging systems allow the maintainer to specify the lowest version their software is compatible with. Of course, it may be that the maintainer always specifies the latest version,

The maintainer does not specify a version and expects the automatic process of determining minimumum dependencies to take over.

But it takes over with dependencies of newer versions than necessary.

Re: Mongrel2 Says, "Goodbye Python"

#230

He's absolutely right. I have come to the conclusion that we must do one thing: Stop sharing. Shared libraries and language runtimes are a relic of the past when memory and storage were orders of magnitude smaller. Bundle all dependencies and throw out the package managers!

And reinstall your entire operating system when a core library needs a security patch.

Why the entire OS? All applications using a particular library would have to be updated individually, which is a drawback. So be it. Every solution has its drawbacks. I suspect that a system with a labyrinthine dependency graph is less robust and less secure. Don't forget that sharing a library doesn't just mean sharing bug fixes, it also means sharing bugs.
Post reply on HN