Why can't I just use the Ruby that came with my computer?

If you're on a Mac or Linux, you've probably noticed you already have Ruby installed. Trust me, leave it alone. That's called the "system Ruby," and it's there because the operating system itself relies on it for internal scripts. If you start installing gems into the system Ruby, you'll quickly run into permission errors, and you'll find yourself typing sudo gem install—which is a cardinal sin in the Ruby world. Using sudo to install gems can mess up your system permissions and create a security headache.

A version manager lets you install Ruby into your own home directory. This means you have full control, you don't need root access to install libraries, and if you accidentally break something, you can just delete that version and start over without worrying about your OS crashing.

Which manager should I actually use: rbenv, asdf, or RVM?

You'll see these three names pop up everywhere. RVM was the original heavyweight, but it's a bit "magic" (it overrides a lot of shell commands), which can lead to confusing bugs. rbenv is a leaner, more surgical tool that does one thing well: it manages Ruby versions. Then there's asdf, which is what I personally use these days. asdf is a "universal" manager—it handles Ruby, Node.js, Python, and about a hundred other languages using a single plugin system.

If you only ever plan to touch Ruby, rbenv is a great, simple choice. But if you're a full-stack dev, asdf is a lifesaver because you don't need five different tools for five different languages. Here is how a typical installation flow looks with rbenv:

# Install a specific version
rbenv install 3.2.2

# Set it as your global default
rbenv global 3.2.2

# Verify it's working
ruby -v
# => ruby 3.2.2 (2023-03-30 revision 510e4a7d4d) [x86_64-darwin22]

How do I make a project automatically switch to the right Ruby version?

Imagine you're maintaining an old legacy app that only runs on Ruby 2.7, but you're building a new project on Ruby 3.2. Switching manually every time you cd into a folder is a recipe for frustration—you'll eventually run a command with the wrong version and spend an hour wondering why your gems aren't loading.

The solution is a .ruby-version file. It's a simple text file placed in the root of your project containing nothing but the version number. When you enter that directory, your version manager sees that file and flips the switch for you automatically.

# In /projects/legacy-app/.ruby-version
2.7.8

# In /projects/modern-api/.ruby-version
3.2.2

Now, when you move between these folders in your terminal, running ruby -v will show the version changing instantly. It feels like magic, but it's just a small hook in your shell configuration.

Do I have to reinstall all my gems when I upgrade Ruby?

Short answer: Yes. This is a common point of confusion for beginners. Gems are installed into a directory specific to the Ruby version they were built for. If you move from Ruby 3.1 to 3.2, your 3.1 gems won't be available in 3.2.

While that sounds annoying, it's actually a feature. Many gems use "native extensions" (C code) that must be compiled against the specific version of Ruby you're using. If you could just share gems across versions, your app would crash with cryptic segmentation faults. The workflow is always: install the new Ruby version, then run bundle install to fetch the gems for that specific environment.

📋 Practical Task

Exercise: Establishing a Version-Locked Environment

In this exercise, you will simulate a real-world scenario where you must manage two different project environments on the same machine. Follow these steps using your chosen version manager (rbenv or asdf):

• Create two directories: ~/ruby_legacy and ~/ruby_modern.
• Install Ruby version 3.0.0 and Ruby version 3.2.2 (or the latest stable version available).
• Inside ~/ruby_legacy, create a .ruby-version file and set it to 3.0.0.
• Inside ~/ruby_modern, create a .ruby-version file and set it to 3.2.2.
• Open your terminal and cd into the legacy folder. Run ruby -v and verify it reports 3.0.0.
• cd into the modern folder. Run ruby -v and verify it reports 3.2.2.
• Finally, install the colorize gem while inside the ruby_modern folder, then cd into ruby_legacy and try to run require 'colorize' in an irb session to prove that gems are isolated between versions.