As someone who clearly doesn't use Ruby often enough to "get it", I don't understand this problem: I have multiple major versions of Ruby installed on my server from Ubuntu via APT, and I don't need to "switch" between them... they are just versions in their install names like all the other versioned interpreters I install. If I want some kind of "default" build of Ruby, that seems like it would be solved with nothing more than a three line shell script to build either aliases or symlinks (and I think Ubuntu already has a way to do this using diversions).

As Ruby is an interpreter most executables just have "#!/usr/bin/env ruby" at the top of the file. If you have multiple versions of Ruby, this may or may not pick up the correct version you have installed. Historically the interpreter has made quite a few breaking changes, didn't follow semantic versioning and didn't care about backwards compatibility. What these tools do is alter the environment so that you can 'lock' specific versions of the interpreter.

The same problem also occurs with libraries, which may also have their own executables, so these tools have tried to solve both problems - which is slightly more complicated than a three line shell script. Bundler has become the standard way of managing libraries, so now something like chruby[0] can be used to do pretty much what you said for the interpreter alone. Of course the other tools (that do a lot more) still have their historical followers...

If you are wondering why you need to support multiple versions, these tools are mainly for use in development environments where you will probably have to support legacy software that is no longer actively maintained.

[0] https://github.com/postmodern/chruby/blob/master/share/chrub...

It mostly kicks in when you are a developer that supports 4 or 5 different ruby-on-rails sites, each of which require different versions of ruby. Rails, in particular, seems to be very intolerant of running on different ruby versions, so if you have been less than scrupulous in keeping all your rails apps up to date, you will be juggling different ruby versions. Using Debian "alternatives" is one way of dealing with it, but you also need to be hyper sensitive about the gem versions, so you will be using bundler in most cases. Rbenv, et all, just deals with the complexity so that it is hard to make a mistake. It's not impossible to do it other ways, but it is much harder.

If you run the right interpreter (e.g., ruby-2.1), it will know what paths to load gems and libraries from. So that's not the problem.

As others mention, scripts typically just run "ruby" (via shebang or directly), which will pick whatever is the default.

Debian/Ubuntu have the "alternatives" system, which is designed to solve this for any kind of program, but it's virtually impossible to use by humans; there's no single command to switch between versions.

Fortunately, the ruby-switch package [1] wraps the terrible UI in a single command to switch versions. I highly recommend it.

Of course, this switches the version globally. To get per-shell Ruby versions, you will need the other tools mentioned in this thread.

[1] https://wiki.debian.org/Ruby

I use Ruby often, not sure if I quite "get it" either, and maybe I don't really understand what you're saying but I think using rbenv is easier than writing a three line shell script to build aliases or symlinks. ```rbenv global 2.3.0```, and you're set.

NPM is atrociously bad. Bundler is amazingly good.