Ruby developers haven't historically been as considerate to users as Perl, Python or Java developers; they don't strictly follow semantic versioning standards or preserve backward compatibility for dependents. So hacks like this and Bundler have been needed to preserve our sanity.

I wouldn't call Bundler a "hack". It's actually one of the best package managers around IMO.

I don't disagree that it works well; I'm simply arguing that it solves a problem that shouldn't have existed in the first instance.

Bundler and the RubyGems community in general is amateur hour compared to projects with more discipline like GNU/Linux distributions.

It's a different type of community, and I was only making a point about how well designed Bundler and RubyGems are for the purpose they serve. It's very easy to share gems within the community.

It is a solved problem. Good can be come better.

How is it a solved problem? chroot is not user-friendly enough clearly otherwise people would use it instead of virtualenv, rbenv, nodeenv and what have you.

GP is right, there should really be one single, generic virtualenvwrapper-like tool that doesn't give a crap about languages.

Docker?

Docker does not solve that problem...

As a Java developer who used to be a Ruby developer, I can't believe how poorly dependency versioning (and just general Ruby versioning) works. It should be simple to have multiple versions of libraries coexisting on a system. Maven can do it fairly easily.

RVM and rbenv seem like hacky solutions to a problem that is easily solved by specifying dependency versions in your project.

You can have multiple versions of libraries (gems) installed at the same time. Ruby is no worse than Java here. You can easily have multiple concurrent versions of Ruby, too. What rbenv etc do is make it easy to switch between Ruby versions and keep them separate. Bundler is not a hack, and is better than what is offered by some other solutions (pip, NPM).

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.

How does maven deal with multiple versions of the JRE?

You can specify which java version you're compiling and execute (unit and integration test included) within maven execution. Granted it's not rvm/rbenv that literally install multiple version of Ruby.

It doesn't. You just install the latest java and it's fully backwards compatible.

That's not really true. We still run some older Apache camel components that require Java 7. And when Java 8 first came out it had bugs that crippled Solr, it took a long time before that was stable enough to use everywhere.

I'm not sure that's really true, but it regardless misses the point. No matter what language you're using, you'll eventually need to be able to deal with multiple versions of it.

Even if you're running an operation small enough that you can upgrade every single runtime in use all in one step, you'll still need to have two versions around while you test. But many, many places have to deal with multiple language versions simultaneously. E.g., if you maintain an open source library and have any regard for your users, you have to test how it behaves in multiple language versions.

Well Ruby is too. If something worked on 1.9 it works on 2.3.

Yeah? Try rails 3.2.17 which work perfectly on ruby 1.9 and see how well it works on 2.2.

(java is not fully backwards compatible either, but it may be a bit more tolerant in some cases)

I've done the work before to make rails 3.2 work on 2.2. I recall the problem is due to a breaking Bcrypt name change and Yaml serialization, and it's a one line patch. The maintainers are aware of the issue but held back so as to not break every 3.2 installation on a minor upgrade (would have to be called Rails 3.3 for semver?). Rails 4.0 isnt that hard of an upgrade path if you include the attraccessible gem.

It took quite a while before rails released a version of 3.2 that worked.

As for how fun upgrading to rails4 is, you obviously don't have a project with 200 database tables that has models using the attr_protected for the five columns (appwide) that actually need it. Forced whitelisting is not fun, regardless of if it is on model or controller level.

Rails isn't ruby.

Did I claim that? However, it is written in ruby and as such it is a valid counterexample to the claim in the comment I commented on.

It's Ruby on Rails

No, Java is not fully backwards compatible. It may be more backwards compatible compared to ruby, but claiming that it is fully backwards compatible is simple false.

  > It should be simple to have multiple versions of libraries
  > coexisting on a system. 

This is a language issue, not a tooling issue.

I'm not sure you understand. You can have as many versions of a gem on your system as you want. You just can't have multiple Ruby versions of those gems easily without something like rbenv.

Yeah, but that's a serious problem. I can't think of other languages that suffer from this, except perhaps Python.

Why should I have to install a single library in multiple places in my system, if I have multiple versions of Ruby installed? It's a disaster for upgrades and deployment.

Plus, tools like RVM and rbenv seem to depend on a bunch of hacky symlinking and $PATH manipulation to make things work. Ensuring that developers' laptops have the same environment as production boxes is not trivial, no matter what the authors of these tools claim.

What I find annoying is that the core problem they solve boils down to manipulating three environment variables. Where's your ruby? That goes in $PATH. Where am I installing gems to? That goes in $GEM_HOME. Where am I loading gems from? $GEM_PATH. Everything else these tools try to do is icing.

Every time I have issues with rvm (which seems often) or rbenv (occasionally, I use it less), I'm reminded that Modules (http://modules.sourceforge.net/) takes care of this path fiddling and more. Yeah, it's old and it's in TCL and it doesn't solve the "how do I build a new ruby and gemset" problem but it's been working for years on the "how do I switch path" problem. I use module when I build .deb of Ruby and gems.

Bundler solves that problem; rbenv is for switching between Rubies, not Gems.