[__mp]

The whole ruby ecosystem is a nightmare for system administrators. Ubuntu/Debian still ships with ruby 1.8.7 and 1.9.1p0 (which is evil I heard). In order to install a new ruby version one has to most likely compile it from scratch: - Since there are no deb packages and there is no sane way to build deb packages - Overriding system ruby has to be avoided since we manage the whole infrastructure with puppet (yes you can run it with 1.9x). Since we want to keep the ruby environment sane.

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

[regularfry]

> The whole ruby ecosystem is a nightmare for system administrators.

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.

[__mp]

>> It get's really interesting once you use puppet to install an RVM ruby version.

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

[regularfry]

First, you're introducing deployment-time dependencies on network resources you don't control. The worst time to discover just how bad an idea that is is when you've just had a critical server go pop while rvm.io (for instance) is having DNS problems, and you've got clients, bosses and clients' bosses breathing down your neck to fix it.

Second, it implies you've got build tools installed on your production machines. That's bad for security.

Third, I've seen RVM screw up too much to trust it. It's got far too many moving parts, and so far I haven't found anything I need which it does that isn't done better by some other simpler tool.

[disbelief]

Isn't it more Ubuntu/Debian's fault for shipping outdated versions of ruby than it is the ruby ecosystem's fault for simply having older versions?

[regularfry]

Nope. Ubuntu and Debian are not at fault. They have to pick a version of Ruby which runs the user applications that Ubuntu and Debian package, which will be kept working throughout the support period of the OS release. Everything else is secondary. They don't get to upgrade versions half-way through the release cycle, either.

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.

[judofyr]

Ubuntu/Debian does not ship with Ruby 1.9.1. They ship with Ruby 1.9.3 under the name of "ruby-1.9.1" because they are ABI compatible.

[__mp]

Ah yes, I was confused by the ABI level. They ship with 1.9.3p0 which you shouldn't use. The currently recommended version is 1.9.3p392 or p194...

[jtdowney]

Debian Wheezy (current stable) ships with Ruby 1.9.3-p194 + various patches [1].

[1] http://packages.debian.org/wheezy/ruby1.9.1

[__mp]

Ah yes, we're currently running Ubuntu 12.04 LTS.

[tacticus]

ubuntu 13.04 is ruby 1.9.3p194 which i believe was the default for 12.10 as well