Seriously I thought ruby was supposed to be a beacon of simplicity? Someone please tell me there's a light at the end of this tunnel.
Edit: Some folks have mentioned getting the RVM. I think I was unclear when I just said I've been fighting with ruby versions - I meant that all of this was done with RVM/gems/bundle/etc, but it's still been a p.i.t.a.
You do not need a version manager to give Ruby a try. Although, it's a nice thing to have. If you decide to use one, you basically have 3 options: 1. rvm (most popular and bloated), 2. rbenv (simple), 3. chruby (even simpler).
If you can, I advise you to switch to Ruby 2.0. It's faster, got a lot of new features and it's becoming the default in the community.
Last piece of advice, do not mix up Ruby and Rails :)
But if you are actually trying to build something to use long term - as crappy as it is to hear it now, it is not a great idea to use the system version of ruby. since it is likely as you get into ruby that you will have multiple projects which amy or may not require different subversions of ruby, you should always use rvm. it allows you to install multiple versions of ruby side by side.
also, check out https://github.com/tokaido/tokaidoapp
If you're using Homebrew, you can install rbenv, ruby-build, and then use rbenv install to install a new Ruby version. Homebrew has its own version of Ruby, but it's the latest version and it's more maintainable to use rbenv or RVM to manage Ruby installations. It's sort of a pain, but once everything's set up, you won't have to think about it again.
rvm instal ruby-1-9-3-p429
RVM setup guide:
http://www.stewgleadow.com/blog/2011/12/10/installing-rvm-on...rbenv setup guide: https://gist.github.com/jasoncodes/1223731
It get's really interesting once you use puppet to install an RVM ruby version. Which you then use to install $GENERIC_RUBY package (ie Gitlab) via Puppet.
I don't want to talk about the mess called "Puppet"...
It's getting better.
John Leach over at Brightbox has a ppa with up-to-date binary ruby packages: http://blog.brightbox.co.uk/posts/next-generation-ruby-packa... https://launchpad.net/~brightbox/+archive/ruby-ng-experiment...
I'd suggest giving them a go, and mirroring them inside your infrastructure if they work for you.
It's very annoying that checkinstall doesn't Just Work for recent ruby builds. If it did, I'd suggest that every time.
> It get's really interesting once you use puppet to install an RVM ruby version.
Yeah, don't do that.
> Yeah, don't do that.
Why not? Puppet-RVM (https://github.com/blt04/puppet-rvm ) works very well. And puppet is basically a system documentation. Since it's clear what's installed on the machine.
This is why it's not realistic to expect to use the system ruby for development: that's not what it's there for.
It's also worth noting that the version of Ruby in current Debian Stable (which is 1.9.3-p194) will in all likelihood be deprecated by ruby-core 2 years before the next Debian Stable release. Again, this is fine for Debian, because they have taken on the responsibility of keeping working the user applications which rely on the system ruby.
If you're complaining about the system ruby being so out of date that you can't develop applications on it, you're doing it wrong. The system ruby isn't for you.
At least 2.0.0p195 is indeed in Mavericks.
I have no problem with keeping software up-to-date but I don't want to make that a main task because some "cool" kids easily get bored and keep phasing out stuff which break production apps and/or causes security issues.
If you were responsible you went through several patchlevels of Ruby 1.8.7, you're using the latest release (to fix security issues if nothing else) and you had five years to migrate to 1.9 (which most likely meant changing nothing in your code, just testing it).
If you were not responsible and you're running on something different to the latest patchlevel version then you're already running on faulty/unsecure software. Killing support upstream (again, after five years!) is not likely to change whatever you were [not] doing.
PS: Please don't refer to people like the ruby-core team as "cool kids who easily get bored". We all have our biases but name-calling doesn't add anything useful to discussions.
Given that you were at the project right from the start and allowed to spend time necessary. It's funny to hear people moan on the one hand about corporate that use Java EE or even Cobol but on the other hand refuse to accept that in order for their software to be usable, it needs to be stable in some senses.
Which Python exactly? 2.6? 2.7? 3.3? That a Python user of all people would whine about lack of stability and consistency is extremely funny.
Phasing out old version of the underlying language isn't uncommon. For example, Oracle doesn't even support Java 6 anymore, which was released in 2007.