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.