Hacker News Reader

Comment by JeremyBanks | Hacker News Reader

I failed to find a reference, but I seem to remember the Python team deciding at some point that they intended to keep the name "python" for the Python 2.X binaries perpetually, and require Python 3.X to be invoked as "python3". Arch might be alone in making this change, and inconsistent with other Python distributions.

EDIT: I can't find a conclusive decision but here is one discussion on the subject: http://mail.python.org/pipermail/python-3000/2008-February/0...

View on HN

Arch has done this before. They only provide Ruby 1.9, even though 1.8 was (and remains today) the norm. I tried pointing this out and they told me to use a community package, which is unreliable and a huge pain. Their package philosophy is bleeding edge to an absurd degree, as it simply doesn't work. I stopped experimenting with Arch because of it.

Ruby 1.8 is god awful and should be taken out back and shot. Several times. In no way should anything be done to support 1.8 as "the norm", especially after 1.9.2.

Also, it's not like anyone should be using the system Ruby anyway. That's really bad practice in my opinion and there's no excuse when rvm exists.

I don't use RVM, and I've got a few excuses:

RVM doesn't work with fish. Fish is the biggest innovation in command-line shells in so long, and I'd rather drop RVM than drop fish.

Also, RVM hijacked my 'cd' command, so that 'cd' wouldn't take me back to my home directory any more.

I don't like things messing with workhorse commands that I depend on - 'cd' has to work.

'cd' hijacking is definitely a bug. I can't reproduce that behavior. How long ago did that happen? Overall I've found rvm to be very solid software.

Not a bug - it's part of RVM's design.

RVM reads .rvmrc files in each directory you change into. How does it do this? By redefining 'cd' to be a function wrapping the real CD command, with some extra RVM stuff in between the changing of directory and return.

Check it out: http://github.com/wayneeseguin/rvm/blob/master/scripts/cd

My problems ('cd' with no arguments didn't take me back to my home directory any more) occurred about a month ago (I was using the fish interop mode - that might have been the problem), and it's probably been fixed since. But the whole thing scared me out of continuing with RVM.

If there's a bug in RVM, I sure as hell don't want it to manifest in my 'cd' command. I need to be able to change directory, and my scripts rely on it to always work.

True, but those of us who have jobs working with ruby work with 1.8.7. We can't all rewrite our code from scratch you know.

Well if you're not living on the bleeding edge of Ruby why would you live on the bleeding edge of Linux with Arch? Any job that requires Ruby 1.8 shouldn't be using Arch.

Python3 is almost 2 years old this decision isn't about the bleeding edge, it's about damn time.

yeah.. in Python world it's still pretty bleeding edge. There's a reason they kept going with 2.7 in parallel with 3

Would you consider Linux 2.6 'bleeding edge'? I mean, they have kept the 2.4 series going. Just because some development occurs in parallel, doesn't mean the new version is 'bleeding edge'.

The Python 3 migration process, for actual Python software in the wild, is and has always been meant to be a multi-year thing. As such, Python 3 is still very much "bleeding edge" in the sense that most projects are still working on their migration, and likely will be for some time.

I don't understand why more people don't get that. Guido has always said it will take a few years for it to all get over to P3. The Django folks are just now deciding when to get Django over to P3. If I have been watching the release notes for P3 versions as they come out and it still seems they are "cleaning up".

You're correct, but you misunderstood me:

I'm not saying it's bleeding edge because they're developing in parallel, I'm saying they're developing in parallel because it's bleeding edge.

It's bleeding edge because the developers explicitly refer to it as "the shiny new thing", etc.

On the other hand, making your software work with Ruby 1.9 is something you'll have to do anyway, sooner or later. As long as there are no release-critical bugs in Ruby-1.9 ... which I guess aren't, because otherwise I don't think Arch would provide them.

"bleeding edge" doesn't usually refer to released software.

Tangential, however I have found rvm to be incredible helpful in such situations. The ability to run multiple versions of Ruby with various sets of gems makes developing Ruby 1.8/1.9 apps painless. So much so that this is my default mechanism of running ruby anywhere (dev/prod).

http://rvm.beginrescueend.com

Even Slackware only provides 1.9.x now.

Use RVM if you still need 1.8.x for something.

This is one of those special case situations, since 1.9 has been the stable branch of Ruby since January of '09. That said, you're right, a sizable number of projects have stuck with 1.8.x, but you also can't blame the guys from Arch, either.

1.9.2 should change this.

I haven't found that their package philosophy "simply doesn't work." It's worked pretty great for me. Maybe we're doing different things, though.

Reply on news.ycombinator.com