Question
Local Gemset vs System Ruby: Which Ruby SDK Configuration Avoids Production Failures?
Lax Atlas
0 reputation · 21 Nov 2024, 12:30 UTC
29.1K views
Loading…
0 reputation · 21 Nov 2024, 12:30 UTC
Ensure that a RubyMine project runs with the same dependencies locally and in production, preventing “works on my machine” failures during deployment.
RubyMine automatically selects the interpreter defined in project settings, but it does not apply the gemset specified by .ruby-version or .ruby-gemset unless the developer explicitly adds the gemset to the Ruby SDK list or configures Bundler to use the system Ruby. This mismatch can cause locally installed gems to be missing in a production environment that uses the system Ruby.
Should developers enforce the same Ruby SDK (and gemset) across all environments, or should they rely on Bundler’s “Use Bundler” option to run commands against the system Ruby?
Use a local gemset managed by a version manager (rbenv, RVM, or chruby) and configure RubyMine’s SDK to point to that ruby + gemset. In CI/CD, install the same ruby version manager, set the same .ruby-version/.ruby-gemset, and run bundle install. This guarantees identical gem versions across dev, CI, and production.
rubymineruby -v, gem list, and bundle env show the same paths in all environments.If RubyMine only sees the system Ruby, gems installed into the local gemset are invisible to the IDE, leading to false‑positive inspections and, more importantly, a mismatch between what the developer runs locally (gemset) and what the CI pipeline sees (system Ruby). Adding the gemset to the SDK list makes the IDE aware of the exact gem set, but it does not automatically propagate that setting to CI; CI must be configured to use the same ruby version manager and gemset.
.ruby-version and .ruby-gemset (or a .tool-versions file) to the repository.Preferences → Languages & Frameworks → Ruby SDK and Gems → + → New SDK and select the ruby binary from your version manager; the associated gemset will appear automatically.rbenv install $(cat .ruby-version) (or RVM equivalent), then rbenv shell $(cat .ruby-version) and rbenv gemset use $(cat .ruby-gemset) (or RVM rvm use ruby-@gemset).bundle install --path vendor/bundle or let Bundler install into the active gemset; verify with bundle env that gem home and gem path point to the gemset directory.If the production server does not have the same ruby version manager installed, the local gemset cannot be activated there. In that case you must either:
bundle install --deployment --path vendor/bundle) and commit the vendored directory, making the system Ruby sufficient.To decide which path to take, confirm:
Does your production environment already have rbenv, RVM, or chruby installed and configured to read
.ruby-version?
Use comments to ask for clarification. Post a solution as an answer.
29,775 reputation · 21 Nov 2024, 13:32 UTC
To further reduce the risk of production failures, it is worth clarifying the distinction between version managers that support gemsets (like RVM) and those that rely on a single gem home per version (like rbenv or asdf). While the previous response suggests using .ruby-gemset, many modern CI/CD pipelines and containerized environments prefer .tool-versions (used by asdf) or .ruby-version alone.
If you move toward a Docker-based deployment, the "system Ruby" effectively becomes the Ruby version installed in the base image. In this scenario, the local gemset becomes less relevant than the Gemfile.lock. To verify alignment, you can run the following in both your local terminal and your production container:
which ruby
ruby -v
bundle env | grep "GEM_HOME"If the paths diverge significantly (e.g., /usr/bin/ruby vs /home/user/.rbenv/shims/ruby), ensure your CI script explicitly sets the GEM_HOME or uses bundle install --deployment to isolate dependencies from the system Ruby entirely.