It's redundant to use RVM's gemsets if you're using bundler.
Conflicts when using Bundler arise primarily for two reason:
- Using gems that require other gems without precise version specifications.
- Executable conflicts: you have both rails v3 and v4 installed, so where do we go to when calling
rails g migration or calling rake?
The first issue can be resolved if you're careful about specifying your gem versions more explicitly in your Gemfile.
When working within a project with a Gemfile, the second issue can be resolved by prefixing executable calls with bundle exec, which will run the command within the context of the current bundle (e.g. bundle exec rake db:migrate).
When you want to specify a gem version outside of a Gemfile's context (e.g. rails new fancy_app), you can specify any gem's version by providing it as the first argument surrounded by underscores.
rake --version
rake _10.3.1_ --version
rails new rails_latest_app
rails _3.2.12_ new rails_3_app
rails _4.0.4_ new rails_4_app
RubyGems handles all of this for you by creating version-aware wrappers for any gem's executables. Just run cat `which gem_executable` (with gem_executable being something like rake, rails, foreman, pry, etc.) and have a look.
Stephen Ball has a good blog post about how to use Bundler instead of RVM gemsets, which explores the overlaps in further detail.
While RVM's gemsets are not necessary, RVM provides other conveniences:
- Automatically adding bundler binstubs to the
PATH, so you can avoid typing bundle exec. Note the bundler plugin for oh-my-zsh provides the same feature
- Managing multiple Ruby versions
The ruby version manager rbenv provides similar features as well.