Pular para o conteúdo
LatchkeyLatchkey home

rbenv vs RVM: gerenciando versões do Ruby

O rbenv é um alternador de versões do Ruby leve e baseado em shims; o RVM é mais pesado e traz gemsets e integração com o shell.

O rbenv faz uma coisa - selecionar uma versão do Ruby por projeto via shims e um arquivo .ruby-version - e deixa as questões de gems e build para plugins como o ruby-build. O RVM é mais abrangente, sobrescrevendo o comando cd, gerenciando gemsets e oferecendo ampla integração com o shell. O rbenv é preferido por sua pegada pequena e previsível; o RVM oferece mais recursos embutidos ao custo de complexidade.

rbenvRVM
AbordagemShims, minimalistaFunções de shell, completa
GemsetsVia plugin (Bundler)Embutido
PegadaLeveMais pesada
Arquivo de config.ruby-version.ruby-version / .rvmrc
Melhor paraMinimalista, componívelRecursos tudo-em-um

No CI

O rbenv é simples e previsível no CI, com o ruby-build cuidando das instalações e o Bundler cuidando do isolamento. O RVM funciona, mas suas sobrescritas de shell podem ser complicadas em runners não interativos. Muitos pipelines usam setup-ruby; para paridade local, o rbenv é a escolha mais leve e o RVM a mais completa em recursos.

Acelere

Faça cache do Ruby compilado e do cache de gems com a chave baseada em .ruby-version e Gemfile.lock. Ambos rodam em runners de CI; runners gerenciados mais rápidos encurtam as etapas de build do Ruby e do bundle install.

Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"

What actually changes when you switch

  • Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
  • Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
  • CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
  • Everyone on the team and every runner must move together. Pin the version so they cannot drift.

O veredito

Querer um alternador de Ruby minimalista e componível que se dá bem com o Bundler: rbenv. Querer gemsets embutidos e ampla integração com o shell em uma ferramenta: RVM. Equipes modernas tendem ao rbenv (ou chruby) pela simplicidade; o RVM continua comum em setups mais antigos.

Perguntas frequentes

rbenv vs RVM: Managing Ruby Versions?
rbenv does one thing - select a Ruby version per project via shims and a .ruby-version file - and leaves gem and build concerns to plugins like ruby-build. RVM is more all-encompassing, overriding the cd command, managing gemsets, and offering broad shell integration.
In CI?
rbenv is simple and predictable in CI, with ruby-build handling installs and Bundler handling isolation. RVM works but its shell overrides can be fiddly in non-interactive runners. Many pipelines use setup-ruby instead; for local parity rbenv is the lighter choice and RVM the more feature-complete one.
Speed it up?
Cache the built Ruby and the gem cache keyed on .ruby-version and Gemfile.lock. Both run on CI runners; faster managed runners shorten the Ruby build and bundle install steps.
Which should I choose?
Wanting a minimal, composable Ruby switcher that plays well with Bundler: rbenv. Wanting built-in gemsets and broad shell integration in one tool: RVM. Modern teams lean rbenv (or chruby) for simplicity; RVM remains common on older setups.

Guias relacionados