Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

81–90 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#81

This is a major problem. PETSc uses Python for configuration and we have to be careful not to use any features requiring >2.3. The last release (this spring) required 2.2 because RHEL3 is still supported (in production phase 3, see http://www.redhat.com/security/updates/errata/ ) until Oct 31, 2010. Python is easy to install, but it's a lot to ask of users when they just want to get your software up and running. Note…

This is very interesting and is what RVM in the Ruby world was designed to solve in some way. So maybe we need a widespread and useful PVM. This feeds into an observation of mine I made over five years ago but that seems to be ever more relevant as time goes by. Linux and BSD seem to have "solved" the packaging problem through mega-repositories with dependencies and access to source code. However your favorite language and especially the scripting ones and virtual machines one will have there own repositories that are _not_ linked into the systems way of doing things.

So at the system level we have RPM and Yum and Ports and Portage and Macports and Fink and Homebrew and AptGet and Conary and yada yada yada but at the language level we have (deep breath) Perl and CPAN, Ruby and GEMS, Python and EGGS, and Emacs and ? and Java and Eclipse plugins and on and on.

I would switch IN AN INSTANT to the distro that integrated all this so that I would only need to go to ONE place to upgrade system packages and language packages. Honestly if nobody does it one of these years I might even be forced to do it myself and make mega $ € ¥.

Hope this makes sense to somebody somewhere. :)

Re: Mongrel2 Says, "Goodbye Python"

#82
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!

Re: Mongrel2 Says, "Goodbye Python"

#83
post #49

Earlier quoted context omitted.

In the Git project we target Perl 5.6 for critical code (like git add --interactive) and Perl 5.8 for some other code (like git-svn). Those are 10 and 8 years out of date, respectively. Or the equivalent of targeting Python 1.6 and 2.0. It can be mildly annoying sometimes to have to use 5.6 features when I usually develop on 5.12 or newer, but Perl's policy of backwards compatibility makes this a lot easier than it w…

> equivalent of targeting Python 1.6 and 2.0. I'm less in touch with Perl language development in the past decade, but my impression is that the difference between Perl-5.6 and Perl-5.12 is much less than between these versions of Python and recent releases. This is expected when a language evolves rapidly, but it's rather frustrating to wait 10 years before you can depend on the "new" features being available.

This backwards compatibility is a conscious decision. And it is argued about. To find a bit to read about that, Google e.g. for darkpan. (It is probably one reason why Perl 5 is so extensible.)

Re: Mongrel2 Says, "Goodbye Python"

#84
post #83

Earlier quoted context omitted.

> equivalent of targeting Python 1.6 and 2.0. I'm less in touch with Perl language development in the past decade, but my impression is that the difference between Perl-5.6 and Perl-5.12 is much less than between these versions of Python and recent releases. This is expected when a language evolves rapidly, but it's rather frustrating to wait 10 years before you can depend on the "new" features being available.

This backwards compatibility is a conscious decision. And it is argued about. To find a bit to read about that, Google e.g. for darkpan. (It is probably one reason why Perl 5 is so extensible.)

Thanks berntb! That's a perfect tip for a new submission:

http://news.ycombinator.com/item?id=1712404

The DarkPAN matters

"There is currently some FUD going about in some parts of the Perl community about why we should break Perl 5 backwards compatibility. A short blog entry, schmarkpan, is a good example of the trend: loud, noisy, but clueless and devoid of any content."

Re: Mongrel2 Says, "Goodbye Python"

#85

This is a major problem. PETSc uses Python for configuration and we have to be careful not to use any features requiring >2.3. The last release (this spring) required 2.2 because RHEL3 is still supported (in production phase 3, see http://www.redhat.com/security/updates/errata/ ) until Oct 31, 2010. Python is easy to install, but it's a lot to ask of users when they just want to get your software up and running. Note…

This is very interesting and is what RVM in the Ruby world was designed to solve in some way. So maybe we need a widespread and useful PVM. This feeds into an observation of mine I made over five years ago but that seems to be ever more relevant as time goes by. Linux and BSD seem to have "solved" the packaging problem through mega-repositories with dependencies and access to source code. However your favorite langua…

    have there own repositories that are _not_ linked into the systems way of doing things
One approach is to have a system that packages everything in the language-specific repository for the distro. Haskell on Archlinux is an example of this.

I'm not a fan of actually using the language-specific packages because I like the rolling release model and end up having to do some manual work to reinstall all my packages when the distro upgrades it's copy (or switch to the next 6-month release with Ubuntu and similar).

Re: Mongrel2 Says, "Goodbye Python"

#86
post #18

Earlier quoted context omitted.

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.

Tell me about it! I just wanted to install folding-mode for Emacs the other day, dselect wanted to install a new sodding IM client as well! (Something in emacs-goodies-el depended on it). About 50M it came to!

So I just did it by hand, more like 50k...

Re: Mongrel2 Says, "Goodbye Python"

#87
post #48

Earlier quoted context omitted.

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).

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.

Re: Mongrel2 Says, "Goodbye Python"

#88
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…

Bullshit. We (python-core) are obsessed with backwards compatibility. Adding new features that aren't in old version is the source of this problem.

Python 3 is by far, the biggest intentional deviation from the "don't break existing scripts" mantra that's been in place for years.

Re: Mongrel2 Says, "Goodbye Python"

#90
post #64
post #52

Earlier quoted context omitted.

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 .

I know, but that doesn't necessarily make it a good solution. I've been a sys admin for several large unix systems and variations on the problem Zed describes needed to be hacked around on each and every one of them.

I think we agree. If I were doing an OS now, I'd also ignore the FHS completely, but more to the point: I wouldn't use anything that remotely resembles it either.

/ would have one dir:

/myos

And all OS components are under there:

/myos/bin/python

People can install anything they want outside /myos, but I'd make it very clear that the OS owns this folder and it should not be modified.

Post reply on HN