Rbenv and RVM provide a lot more than just four major revisions of Ruby. They provide explicit, exact version selection down to the exact patchlevel of the release, alternative interpreters like JRuby, Maglev, Rubinius, and Ruby EE. Plus, they are user-installable, and have tools for automatically managing selecting the correct Ruby for a project without having to issue special commands.
Certainly I'd prefer if popular Linux distributions made more versions of tools like Ruby available as packages, but just having Ruby 2.0 and 2.1 installed at the same time is not the only point.
Honestly, the rbenv model is looking pretty good these days given that there's also pyenv, nodenv, and plenv, all direct forks of rbenv. For the servers I take care of, I set up system-wide rbenv and pyenv installs as a non-root user to give our applications the flexibility of these tools without having to screw around with root access where it's unnecessary. It works great, and I'm planning to move Perl to the same model.
If you would be willing to chat about such issues on the IRC channel #perl6 on freenode[1] (usually busiest from around 8am to 8pm EST), especially with FROGGS and/or lizmat, you could help the Perl 6 team as they specify and implement package management that tackles these issues (multiple compiler versions, multiple module versions, alternative implementations by different authors, CPAN/PAUSE, github, local repos, and so on).
I don't understand how the solution described actually solves the problem. There's a (yawn-inducing) solution given for installing Gems outside the Ruby library path (i.e., in one's homedir), but none for actually selecting the version of Ruby to build those Gems against. A Gem with C bindings built against the 1.9.3 shared libraries is unlikely to work (and might not even be found) when subsequently used under 2.0.0.
Yes, although they have a slightly different model.
rbenv basically just chooses which ruby (along with the gems that are installed with it) is active on your system.
rvm also provides a gemset functionality that is more like the virtualenv model, where you can have multiple gemsets per version of the interpreter.
What virtualenv doesn't handle as well as either of them is choosing between installed versions of python. What virtualenv does better than both is create an isolated environment for your python program.
Dovetailing with having multiple rubies, the reason why you have multiple rubies is to support older projects that depend on older rubies, and lock future projects to whatever was the best ruby for it at the time.
Or you're just developing libraries and are trying to be a good citizen of the ruby ecosystem - which includes that you'll try and support multiple interpreters and versions, if possible.
I agree. I don't just use RVM because my OS doesn't have the latest version.. I use RVM because I work on a project that uses jruby, and another that uses 2.1.1, and yet another that uses 2.0.0. Those projects may also require different versions of the same gem. With RVM I can have a .ruby-version and .ruby-gemset file in the projects root and RVM takes care of switching the version and gemset when I move into a projects directory. To quote the article: This seems like a much cleaner way of working!
This post hints at it, but you can install all of those Ruby versions on OpenBSD simultaneously. Ruby 1.8 has its binaries named "ruby18", "irb18", etc. and Ruby 1.9 is "ruby19", "irb19", etc. You can create a symlinks from "ruby" to "ruby19" and "irb" to "irb19" to set a system-wide default but any version can be used.
That still doesn't cover cases where you want to use multiple 1.9 versions, or if you want to test different patches, or if you want to use the latest version before your OS packages it. It's still the same basic problem as on Ubuntu.
Yes, and it's nothing new, you can do the same using Debian and then select the most appropriate version of ruby with update-alternatives... RVM and rbenv do something different, they allow you to _run_ different version of ruby for different apps. The fact that you can use them to set the default ruby for your system* is a quite handy side effect.
* And even then, you don't set the default ruby for the entire system, you set it for your own sessions.
More languages need to go the Leiningen/Clojure route and make the language version work in a way similar to import/require statements or be specifiable in a manifest file. IIRC, with lein you specify the clojure language version you want in the project manifest file.
For interpreted languages, I don't know why we can't just do something like:
#!/usr/bin/env ruby-2.1.1
In the main() file of our application.
Languages in general would be better off designed around having an executable that bootstraps loading the version appropriate for the code you are trying to execute. i.e. the `ruby` executable shouldn't be versioned, but instead be designed to to determine the version of ruby you need and then execute your code using that version. The obvious way is to have user's specify the version they need, but there is nothing stopping someone from creating a tool from each language that does nothing more than trying to parse the AST for a language and searching for tokens and language features that identify that code as being executable with version X, Y or Z. Furthermore, the language could easily keep a key-value db on disk whose sole responsibility is keeping keys that are the absolute path of the file on disk and the values are the mtime and sha256 of the file and the version of the language with which to execute that file when not explicitly stated in the file or program manifest.
This is a good solution if you simply want to keep up with Ruby's development or you usually work with one version at a time, but not for projects where you mix and match. For instance, at my work we use multiple Rubies, including jruby, and a tool such as rvm is a must in this case.
If you're exposing your Ruby to the internet -- as in building web apps with it -- you should strongly consider not using your distribution's Ruby, and relying on a tool that will allow you to install new releases more quickly. There have been some pretty important CVEs issued over the last couple of years. Not having the ability to quickly update, test, and deploy a new interpreter version is a pretty significant liability.
I use rbenv because projects want different versions of ruby, and being able to switch without thinking is very helpful. It's not like I'm lacking up to date copies of Ruby on Arch either.
Hmmm I use RVM for gemsets. Managing and being able to switch between different sets of potentially conflicting sets of gems is a huge use case for RVM!
Certainly I'd prefer if popular Linux distributions made more versions of tools like Ruby available as packages, but just having Ruby 2.0 and 2.1 installed at the same time is not the only point.
Honestly, the rbenv model is looking pretty good these days given that there's also pyenv, nodenv, and plenv, all direct forks of rbenv. For the servers I take care of, I set up system-wide rbenv and pyenv installs as a non-root user to give our applications the flexibility of these tools without having to screw around with root access where it's unnecessary. It works great, and I'm planning to move Perl to the same model.