Here's how it usually works: We're coasting along with some tool and doing well, then some dev announces that we're ALL WRONG because another tool is better. Sometimes the tool he's announcing is something like git when we're using TFS, and we switch. Other times, say RVM vs. this right now... I just don't see a big gain.
1.) Ends with the same net result for the developer, and 2.) Adds a little bit of complexity on setup and rules around use, then
why switch? I'm perfectly willing to trade up my development tools, but I want a better net gain before I switch.
Perhaps that net gain will be to keep up with a growing number of devs who use it? We'll see.
Personally, I never have trouble with rvm. It works great despite a little magic and I like the way that I can use it without having to worry about installing bundler, installing binary shims, etc.
Speaking of attitudes affecting the Python community, does it have anything approaching the ease of use of rbenv or rvm yet?
Let me predicate this by pointing out that I manage a lot of Ruby projects (many are old) that require a wide variety of Ruby and gem versions. Obviously my solution isn't the best for everyone. Some developers will never have to worry about conflicting gem versions, because they work primarily on one project with one set of dependencies. The incremental value of the items I'm about to point out don't represent significant value to them. Enough with the disclaimers.
Bundler has the ability to alter your Ruby env variables so that you can easily install and execute gems from any location. This is the feature that allows you to use completely different gems across many projects without any conflicts. As the author suggests, you can pass a path at the time you invoke `bundle install` as a means to specify this location. This allows you to segregate gems to avoid conflicts. The author also points out that the trade-off is "one annoying side effect: any binaries that are installed (e.g. rspec, foreman, cap) are no longer available in your shell’s path". Bummer. I wonder if there's a way around that? Hey, we could manage our environment so that these items are in our path, but remain segregated. We could even write some tidy scripts that automate it for us. Enter RVM.
This is why I don't understand the drive to move to rbenv for developers who need these features. I use RVM and bundler all the time. RVM doesn't preclude the use of bundler, and bundler doesn't make RVM obsolete. When I establish an RVM gemset and .rvmrc, I've abstracted away all the '--path=./.somebundledir' and `bundle exec` nonsense. I only think about it once, then I'm free to use the tools without additional cruft. I'm probably happier than I should be that I can type `cap staging deploy:pending` instead of `bundle exec cap staging deploy:pending`.
If you don't need gemsets, or you're only managing a very small number of Ruby projects, I suppose I can understand wanting a simpler tool, but I don't find RVM terribly complex. A lot of people will say "choice is good", but principle applied without cause isn't good, it's just pedantic.
I don't want to get in to the rbenv vs RVM debate - they're both good tools and it's an issue that has been done to death. I linked to five articles in the post, and you can find many, many more with a simple Google. My personal motivation for switching was that bundler's overridden 'cd' function includes some commands that fail, which is fine under most circumstances but it breaks as soon as you use 'set -e' in bash. We spoke to the author and he said he said that RVM wouldn't be 'set -e' compatible in the foreseeable future.
My observation is that rbenv users often tack on additional ad hoc solutions to arrive at the same convenience provided by RVM. The primary objection I hear to RVM is the `cd` override, which is optional.
For --path, I just use the default which presumably puts everything in the main rbenv folder for gems. I've never had a problem with this.
For the problem of having to type "bundle exec" before every command that uses a binary from a gem, I've heard of two alternative solutions. One is aliasing "bundle exec" to "be" or something to make it quicker to type. The other is using zsh/oh-my-zsh instead of bash and using a plugin (can't remember the name off the top of my head) that automatically figures out what should be bundle execed and takes care of it behind the scenes. I've never had trouble with this either.
I've also used shell plugins to remedy the bundle exec issue, but they've often caused more problems than they solve. I'd much rather just stick something in my PATH than use shell plugins.
I think it's a more correct solution as well. You won't have any guarantees that Bundler will resolve the dependencies correctly in production when it doesn't in your development environment.
I suppose if you're someone who has to work with multiple Ruby versions, it COULD save you time switching between them.
