[integraton]

They are tools for managing multiple installed versions of a programming language. When developing software, we often specify dependencies using version numbers, which indicate the version of the language or library that should be used when running the software. Running the software with the specified language runtime or library version ensures that the expected features of that library or language runtime are available and also helps avoid unexpected issues related to differences in the environments, including different developer's local systems as well as remote server environments.

In the case of a programming language runtime, if you have one project that's configured to use version 2.2.4 of a language and another that's configured to use version 2.1.0, these tools provide an easy way to install and switch between the two versions.

This is not unique to Ruby, and similar projects exist for other languages. For example, nvm (https://github.com/creationix/nvm) and n (https://github.com/tj/n) provide something similar for Node (JavaScript), gvm (https://github.com/moovweb/gvm) for Go, and multirust (https://github.com/brson/multirust) for Rust.

[mfisher87]

I've dabbled a little bit in Ruby, and I found this to be a much larger problem than it is with Python. Most systems have python 2 and/or python 3. Beyond that, I've rarely need to worry very much about which Python version I have. But for every new Ruby application I install on my machine, I'm messing around with rvm.

Is it truly a difference between the languages release strategy or is this just my perception because of limited experience with Ruby? I found it to be a huge pain in the ass.

[lars512]

It's annoying for sure, and I like that we don't need it in Python land. But, in situations when we do want to target multiple Python versions, an identical approach using pyenv works well. I've come to appreciate it more.

[lyime]

It's not really a problem per say. It's just taste really. There are multiple good options for managing ruby versions and environments. (as well as other languages like Phython, see pyenv). I don't necessarily switch to ruby versions between projects or with frequency. That being said, ruby is in active development and with new versions there are many improvements to performance and security. So developers like to try the latest and test out their apps, libraries and frameworks.

[cheapsteak]

I'm sorry I wasn't more clear, I'm wondering why there seems to be a war of sorts between which version manager to use for ruby. Are the differences between rvm, rbenv, chruby, ruby-install practical or purely ideological? There doesn't seem to be this kind of disagreement over which version manager is best in other languages, just ruby, why is that?

[djur]

There's a lot of reasons, but the most significant one is that Ruby successfully and recently made a compatibility break between versions (1.8 and 1.9), which made the ability to run multiple Ruby versions on a single machine extremely important to a large group of people. Toss in alternate implementations like JRuby and Rubinius and it's almost indispensable.

The Ruby dev team tends to prefer encouraging the community to implement competing solutions rather than adopting any of them as official. Ruby devs in general tend to be members of the "there is more than one way to do it" camp.

There isn't really much of a "war". The different version managers came to an agreement on certain things like the format of .ruby-version files, so at this point it's a personal choice akin to which text editor you use.

[whistlerbrk]

rvm hooks into the cd command which has caused people nightmare-level debugging marathons. rbenv's key feature was that it did not do that and uses a shim instead.