Why manage something manually when there are good tools to abstract it away in to the background? That's kind of the feeling I get when using rbenv + bundler.<p>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.<p>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.<p>This is why I don't understand the drive to move to rbenv for developers who need these features. I use RVM <i>and</i> 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`.<p>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.