How to remove all old Ruby versions (and version managers) and reinstall a single, tested version on macOS 10.14.6?

Question

How do I remove (all old Ruby things), reinstall (preferably one and only one Ruby version), and test my entire Ruby environment (versionmgrs, gems, however this works) on my macOS 10.14.6 system using the "Ruby-community preferred" method (some install/version manager or similar vehicle)?

I'm seeking the entire procedure, for everything Ruby-environment related: Ruby "engine," version managers, .bash_profile edits, etc.

Even though we (my team) are not Ruby developers, we're running several Ruby-based apps like Asciidoctor. As such, we're simply users and are not invested in learning all the ins-and-outs of Ruby other than just trying to get apps (like Asciidoctor) to run without problems, and that's it.

1. Remove.

I want to completely remove every little Ruby file found on the system (besides the Apple.com-based default Ruby stuff that comes with macOS--I do not to remove or even use that stuff, ever, if I can avoid it). Hombrew-based, rbenv, and rvm, and any other Ruby thing/version_manager/intstalled_directory (there seems to be lots of different procedures and no one "standard install procedure--which is all confusing to us).

So please consider all the historical Ruby-isms that might have been installed for the entire history or Ruby, because chances are I've been installing them since the very early days of Ruby, and I/we still have the same macOS image we've been carrying forward (across upgraded MacBook hardware).

And it seems to make most sense to make sure this stuff is all gone (or at least moved out of a functional path) to ensure we have a clean slate to...

2. Reinstall.

What exactly we're installing and why we're installing it is unclear. Why do we need something to manage versions of Ruby, when we only want one? Is there some reason why we need multiple versions of Ruby? And do we have to separate Ruby "things" separate from a Ruby "version manager"? Is there a "Install Ruby for non-Ruby-developer dummies" resource to help guide us through this?

(I'm not familiar with the term "version manager" to describe the actual version of interpreter/compiler software. I'm used to, as a long-standing swdev manager, managing versions of the software my teams are developing. We're guessing this may be driven by the Ruby world may not try to enforce as much cross-Ruby-version compatibility, but we only speculate. Granted, we tend to do more system programming in C/C++/Python kind of things, and less web-specific stuff like JavaScript/Ruby things. Maybe the latter has less of "I'm a developer and I do not write portable code across version platforms / I'm a programming-language/platform designer that cares less about cross-version compatibility." This is a new world for us.)

3. Testing.

When done with #2, I would like to automatically diagnose my entire Ruby environment with a comprehensive system test. Is this feasible?

If I do not do this, history tells me that I'll run into a Ruby-wonky-environment problem later. If possible, I want to get "set and forget it," for everything, all in one shot and avoid running into future problems.

Think historical things like make test (after make and make install) and brew doctor.

More details

My Ruby environment/subsystem on my macOS 10.14.6 was wonky and broken and frustrating. Said environment was result of many years (decades) of Ruby stuff/layers piled into my macOS environment (which was cloned across MacBooks over time and therefore carried forward).

I tried to rebuild it and clean it up to try and get some level of sanity. It mostly (?) seems to work, at least for running. But rvm related stuff is still failing--and do I even need rvm (it's unclear, like many things in Ruby setup for non-Ruby developers). And I still have lots of ruby-isms hanging around in .bashrc that looks unhealthy (why so many $PATH entries..?), or at least makes me uncomfortable.

I've found at least 20 different "reinstall / rebuild" references on StackExchange.com and other places, many of which offer different Homebrew-based procedures.

My gem env output. Note all these different versions associated with some ruby-like component:

3.1.2, 2.7.0, 2.7.1, 2.2.1, 2.2.0, 1.1.2

That's six different subsystem versions. In my book, that's bad.

(I'm not a Ruby developer, so pls pardon my poor Ruby "syntax.")

Apparently Ruby community members are fixated on the concept of multiple versions of Ruby installed on one OS; from a classic, old-school system-administrators perspective (that's me), multiple installed Ruby versions is something my team specifically wants to avoid. Maybe there's some need to install multiple Ruby versions on one system. Maybe it's because Ruby offers less-stable environments (features, APIs, etc) than other software systems we're used to. Regardless: without knowing more, I'd much rather manage multiple versions of Ruby with containers (like Docker).

From the perspective of this user: the Ruby world feels chaotic and unnecessarily complex. With Ruby's popularity, I'm sure there's some reason for this. My guess: Ruby values feature advancement over platform stability. This is not greatest thing when I'm wearing my sysadmin hat; it can be kind of fun when wearing my swdev hat. For this mission, I'm only wearing my sysadmin hat.

Answer 1

Use a Full-Fledged Ruby Version Manager

You're trying to install one or more Rubies using Homebrew, and then hoping your gem environment stays sane. Don't. Just don't.

Installing Rubies via Homebrew can exhibit weird conflicts and difficult-to-resolve error messages. You'll be much better off installing a Ruby version manager like chruby, rbenv, or RVM. Not only will this generally work better, but it will segregate your gems on a per-interpreter basis so that you can easily clean up your Ruby environment when you inevitably run into problems with gems, libraries, or Xcode upgrades.

You'll need to install Xcode and its command-line utilities. Beyond that, I'd suggest chruby and ruby-install as the simplest integration solution, but any Ruby manager will do if you set it up correctly.

Answer 2

I usually use RVM when I work on Linux OSs. However, there was a time when I worked on macOS. I tried many times to install RVM on macOS but was never successful, so I tried rbenv instead. It had its differences from RVM, but it did the job for me.

It might not be the answer you're looking for, but in case it is, here are the steps to install rbenv:

1. Type brew install rbenv in terminal to install rbenv.
2. Add the command eval "$(rbenv init -)" to ~/.bash_profile to make rbenv load automatically when you open terminal.
3. Type source ~/.bash_profile in the terminal to apply the changes you made to the current shell session.

4. Type type rbenv in the terminal to verify that rbenv is setup properly. Your terminal should display the following:

   rbenv is a function
   rbenv ()
   {
       local command;
       command="${1:-}";
       if [ "$#" -gt 0 ]; then
           shift;
       fi;
       case "$command" in
           rehash | shell)
               eval "$(rbenv "sh-$command" "$@")"
           ;;
           *)
               command rbenv "$command" "$@"
           ;;
       esac
   }
   

And now, to install Ruby versions:

• To check for available Ruby versions for installation, type rbenv install -l in the terminal.
• To install Ruby 5.5.0, type rbenv install 5.5.0 in the terminal.
• To check for installed Ruby versions, type rbenv versions.
• To make Ruby 5.5.0 the global Ruby version on your system, type rbenv global 5.5.0 in the terminal.
• To make Ruby 5.5.0 your Ruby version in your current directory, type rbenv local 5.5.0 in the terminal.
• To check your current rbenv Ruby version, type rbenv version.
• And of course, type ruby -v to make sure that the setup was done correctly.

Answer 3

(Please make sure to see the Background section at the end of this answer.)

My procedure

1. Remove all the existing Ruby stuff (except for the Ruby "system" files installed by Apple for the "core system" for macOS).

This is the part of the procedure I'm less sure of. I've asked on superuser.com about "how to remove all possible, old Ruby cruft" and will import anything learned there to this procedure. In the meantime, I found a few things Ruby-related (eg: ~/.ruby-version) for which I could not easily find any documentation/reference. It was a mini adventure. But here's what I came up with:

a) Homebrew-based stuff: brew uninstall ruby ruby-build rbenv and any other Ruby-oriented Homebrew packages. brew list | grep can be helpful to find the packages.

b) rvm uninstall -- but please first read "old file droppings" notes below, in order to retain your old rvm environment for reference.

c) Any other uninstalls (non-Apple-macOS systems installs, of course) you can find or think of, possibly including installs that result from procedures found at https://rvm.io and https://github.com/rbenv/rbenv and any other version managers you can find/think of.

2. Remove or move old Ruby file droppings from $HOME

I moved the files instead of removing them, per the following procedure. Note that the ~/.rvm move effectively does some or all of the (1b) procedure above, while retaining the old ~/.rvm environment for (possibly very-helpful) reference, eg: to rebuild your installed-gems list. Also note that you may have more or less "file droppings" in your home directory.

 cd $HOME
 mkdir -p .ruby-old-files/2020-04-13
 mv .rbenv/ .rvm/ .gem/ .ruby-version .ruby-old-files/2020-04-13/

3. (Re)install the latest, "stable" (?) rbenv/"ruby engine" per this one-line command (this presumes Homebrew is already installed), given the rbenv version manager choice as described in the Background section below:

brew update
brew install rbenv

The above does not install the "Ruby engine" via Homebrew; rather, it install rbenv (via homebrew), which in turn installs the "Ruby engine" per the following:

rbenv install $(rbenv install -l | grep -v - | tail -1)
rbenv global $(rbenv install -l | grep -v - | tail -1)

4. Comment/delete previous ~/.bash_profile updates from past Ruby-isms

I ended up commenting out all these lines from past Ruby-driven updates, which appear to be unused by and/or conflicting with rbenv (your file may not have anything like this):

#export PATH=$PATH:~/.gem/ruby/1.8/bin:/usr/local/opt/ruby/bin
#export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting
#[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
# export RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@1.1)"

5. Add this to ~/.bash_profile:

eval "$(rbenv init -)"

6. Start a new macOS Terminal.app window (or iTerm2 or similar).

7. [Optional] Re-install previous gems in new environment.

I looked at my previous .rvm bin list:

$ brew install tree
Warning: tree 1.8.0 is already installed and up-to-date
To reinstall 1.8.0, run `brew reinstall tree`
$ cd
$ tree -a .ruby-old-files/2020-04-13/.rvm/gems/ruby-2.2.1/bin/ -C | less
.ruby-old-files/2020-04-13/.rvm/gems/ruby-2.2.1/bin/
├── 3llo
├── _guard-core
├── asciidoctor
├── asciidoctor-safe
├── bundle
├── bundler
├── coderay
├── console
├── executable-hooks-uninstaller
├── github-markup
├── guard
├── imap-backup
├── listen
├── nokogiri
├── pry
├── rake
├── rdoc
├── ri
├── ruby_executable_hooks
├── setup
└── thor

0 directories, 21 files
$

(there's possibly other places to look for existing gems, as with Ruby stuff can be scattered all over the place with many "rubies" as the Ruby community calls them) and ran gem install [gem-package] for every package I wanted to reuse in my new (clean, fresh, and sane) Ruby environment. I ran some initial asciidoctor tests on my team's rather complex asciidoctor document library, and all seems initially good.

We'd prefer there be some sort of significant Ruby-engine set of "self diagnostics" (a simpler illustration: brew doctor) to give the user much more confidence that their "Ruby engine" is optimally functional. Alas, I as of yet see no such thing for Ruby.

From here moving forward I can gain more confidence in building multiple "rubies" via rbenv, and only rbenv. Before I had multiple rubies managed via multiple installers/version managers (Homebrew, rvm, and rbenv), which may have been a cause of many problems, possibly per Todd's point.

Background

Ruby has a bit of complexity and possibly runs much better with a version manager. I find this all a bit unusual, at least from my decades of swdev+sysadmin experience. I can certainly see how all these mechanisms can be very powerful. For now, I'm just trying to make my Ruby platform work.

From what I can tell, there is no "one standard way" to install and run and a standard directory to places in for Ruby on macOS. This means there's no "one standard way" to uninstall, and so one has to, if they've (often very unknowingly, like me) installed many different Ruby versions (I guess called "Rubies"?) over the years (decades?) in many different files/directories controlled by multiple different "version managers" (I guess? More on versions managers in a moment). ie, I find I have to "hunt and peck" for all the historical ways past Ruby installs/version_managers might have left file/directories placed in various areas.

Note this can happen when you have an macOS image that has lived for many years, and in my case, has been cloned across many generations of MacBooks. For someone who goes to a Ruby boot camp for a week and installs on a clean system, everything should work just peachy. For someone like me who's been an engineer/mgr for decades and possibly has all sorts of Ruby-isms laying around for his decades-old macOS image (as directed by many many different Ruby-based apps/guides on how I install stuff; not knowing that many of these procedures were effectively in conflict with each other), it can be quite the different story.

The Ruby platform apparently requires something called a Version Manager to run a Ruby platform (interpreter, compiler, engine, whatever it's called). I chose the rbenv (based upon this reference) version manager for the "install" portion of my procedure after removing/moving all the old stuff.

If it's not already obvious, it's (presumably?) best to avoid installing and running multiple version managers concurrently.

Installation options

There seems to be several ways to install the Ruby "core engine/platform" (my syntax, possibly only used by me) on macOS, with the 3-most-referenced options I've found noted below. (Note there are many other version managers to choose from not listed below.) I chose rbenv based upon this reference.

1. via rbenv
2. via rvm
3. via Homebrew

(1.) and (2.) above are mechanisms that can install Ruby, and these mechanisms can be installed via Homebrew. But #1 and #2 will not install Ruby via Homebrew. This can be confusing.

It appears (1.) and (2.) also enable multiple versions of Ruby to run concurrently. (3.) may not. This may be helpful due to version-to-gem/app compatibility challenges with Ruby's aggressive (?) feature movement, which sometimes comes at the expense of backwards compatibility. (I'm guessing here, but can come up with no other good explanation; community, pls comment.)

The "remove all old Ruby engines and files" approach might be extreme. My experience: Ruby's history is a mess, and over the years/decades it left all sorts of messy variances (in my home directory) lying around. It's not a big deal for me to rebuild gems by hand -- there's not that many on my system. And by keeping the pre-existing Ruby-environment files around I'm (hopefully) covered if ever I need to revert or rebuild stuff. And, for now, things feel much more "clean and sane" now that it "feels" like I've removed all the old cruft.

Even more background

My team and I are only users of Ruby-based applications, not Ruby developers, and are far from experienced in the Ruby realm. We just want to install and use and maintain applications like Asciidoctor without having to "dive in deep" on all this Ruby stuff. Everything worked okay for several years - and then all the "cruft" built up and started breaking things. When I tore it all down and properly reinstalled (above)--once I finally figured out how all the Ruby ins and outs worked--things starting working again. I believe that I, as a simple Ruby-application user, should not have to go to this level of effort just to get a Ruby app to work. In short: it should not be this hard. Hence the nature of my comments about the difficulty.

Further, I had a bad day when I first posted this question and unnecessarily aggravated several community members here that were trying hard to help--and again, my apologies, that was totally my bad--and I have since been labeled by some as the guy that "likes to complain alot." And I thoroughly deserve that label being inappropriate in a couple of my comments. Again, I apologize.

Additionally: my Ruby problems still exist whether or not folks here want to deny it or simply blame the problems on me for being mean. Regardless: I'm not disappointed with the people trying to help; I'm disappointed with the Ruby platform not supporting my overall experience well.

Please also note TamerB's helpful answer.

Answer 4

Installation On systems with Homebrew package manager, the “Using Package Managers” method is recommended. On other systems, “Basic Git Checkout” might be the easiest way of ensuring that you are always installing the latest version of rbenv.

Using Package Managers Install rbenv using one of the following approaches.

Homebrew On macOS or Linux, we recommend installing rbenv with Homebrew.

brew install rbenv ruby-build

Debian, Ubuntu, and their derivatives Note that the version of rbenv that is packaged and maintained in the Debian and Ubuntu repositories is out of date. To install the latest version, it is recommended to install rbenv using git.

sudo apt install rbenv

Arch Linux and its derivatives Archlinux has an AUR Package for rbenv and you can install it from the AUR using the instructions from this wiki page.

Learn how to load rbenv in your shell.

run this and follow the printed instructions:

rbenv init

Close your Terminal window and open a new one so your changes take effect.

That's it! You are now ready to install some Ruby versions.

Basic Git Checkout Note For a more automated install, you can use rbenv-installer. If you do not want to execute scripts downloaded from a web URL or simply prefer a manual approach, follow the steps below.

This will get you going with the latest version of rbenv without needing a system-wide install.

Clone rbenv into ~/.rbenv.

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
Configure your shell to load rbenv:

For bash:

Ubuntu Desktop users should configure ~/.bashrc:

echo 'eval "$(~/.rbenv/bin/rbenv init - bash)"' >> ~/.bashrc
On other platforms, bash is usually configured via ~/.bash_profile:

echo 'eval "$(~/.rbenv/bin/rbenv init - bash)"' >> ~/.bash_profile
For Zsh:

echo 'eval "$(~/.rbenv/bin/rbenv init - zsh)"' >> ~/.zshrc
For Fish shell:

echo 'status --is-interactive; and ~/.rbenv/bin/rbenv init - fish | source' >> ~/.config/fish/config.fish
If you are curious, see here to understand what init does.

Restart your shell so that these changes take effect. (Opening a new terminal tab will usually do it.)

Installing Ruby versions

The rbenv install command does not ship with rbenv out-of-the-box, but is provided by the ruby-build plugin.

Before attempting to install Ruby, check that your build environment has the necessary tools and libraries. Then:

list latest stable versions:

rbenv install -l

list all local versions:

rbenv install -L

install a Ruby version:

rbenv install 3.1.2

For troubleshooting BUILD FAILED scenarios, check the ruby-build Discussions section.

Note If the rbenv install command wasn't found, you can install ruby-build as a plugin:

git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build Set a Ruby version to finish installation and start using Ruby:

rbenv global 3.1.2   # set the default Ruby version for this machine

or:

rbenv local 3.1.2    # set the Ruby version for this directory

Alternatively to the rbenv install command, you can download and compile Ruby manually as a subdirectory of ~/.rbenv/versions. An entry in that directory can also be a symlink to a Ruby version installed elsewhere on the filesystem.

Installing Ruby gems Select a Ruby version for your project using rbenv local 3.1.2, for example. Then, proceed to install gems as you normally would:

gem install bundler

Warning You should not use sudo to install gems. Typically, the Ruby versions will be installed under your home directory and thus writeable by your user. If you get the “you don't have write permissions” error when installing gems, it's likely that your "system" Ruby version is still a global default. Change that with rbenv global and try again.

Check the location where gems are being installed with gem env:

gem env home
# => ~/.rbenv/versions/<version>/lib/ruby/gems/...
Uninstalling Ruby versions
As time goes on, Ruby versions you install will accumulate in your ~/.rbenv/versions directory.

To remove old Ruby versions, simply rm -rf the directory of the version you want to remove. You can find the directory of a particular Ruby version with the rbenv prefix command, e.g. rbenv prefix 2.7.0.

The ruby-build plugin provides an rbenv uninstall command to automate the removal process.

Command Reference The main rbenv commands you need to know are:

rbenv versions

Lists all Ruby versions known to rbenv, and shows an asterisk next to the currently active version.

$ rbenv versions
  1.8.7-p352
  1.9.2-p290
* 1.9.3-p327 (set by /Users/sam/.rbenv/version)
  jruby-1.7.1
  rbx-1.2.4
  ree-1.8.7-2011.03
rbenv version

Displays the currently active Ruby version, along with information on how it was set.

$ rbenv version
1.9.3-p327 (set by /Users/sam/.rbenv/version)
rbenv local

Sets a local application-specific Ruby version by writing the version name to a .ruby-version file in the current directory. This version overrides the global version, and can be overridden itself by setting the RBENV_VERSION environment variable or with the rbenv shell command.

rbenv local 3.1.2

When run without a version number, rbenv local reports the currently configured local version. You can also unset the local version:

rbenv local --unset
rbenv global

Sets the global version of Ruby to be used in all shells by writing the version name to the ~/.rbenv/version file. This version can be overridden by an application-specific .ruby-version file, or by setting the RBENV_VERSION environment variable.

rbenv global 3.1.2

The special version name system tells rbenv to use the system Ruby (detected by searching your $PATH).

When run without a version number, rbenv global reports the currently configured global version.

rbenv shell

Sets a shell-specific Ruby version by setting the RBENV_VERSION environment variable in your shell. This version overrides application-specific versions and the global version.

rbenv shell jruby-1.7.1

When run without a version number, rbenv shell reports the current value of RBENV_VERSION. You can also unset the shell version:

rbenv shell --unset

Note that you'll need rbenv's shell integration enabled (step 3 of the installation instructions) in order to use this command. If you prefer not to use shell integration, you may simply set the RBENV_VERSION variable yourself:

export RBENV_VERSION=jruby-1.7.1
rbenv rehash

Installs shims for all Ruby executables known to rbenv (~/.rbenv/versions//bin/). Typically you do not need to run this command, as it will run automatically after installing gems.

rbenv rehash
rbenv which

Displays the full path to the executable that rbenv will invoke when you run the given command.

$ rbenv which irb
/Users/sam/.rbenv/versions/1.9.3-p327/bin/irb
rbenv whence

Lists all Ruby versions that contain the specified executable name.

$ rbenv whence rackup
1.9.3-p327
jruby-1.7.1
ree-1.8.7-2011.03

Environment variables
You can affect how rbenv operates with the following settings:

name    default description
RBENV_VERSION       Specifies the Ruby version to be used.
Also see rbenv shell
RBENV_ROOT  ~/.rbenv    Defines the directory under which Ruby versions and shims reside.
Also see rbenv root
RBENV_DEBUG     Outputs debug information.
Also as: rbenv --debug <subcommand>
RBENV_HOOK_PATH see wiki    Colon-separated list of paths searched for rbenv hooks.
RBENV_DIR   $PWD    Directory to start searching for .ruby-version files.
How rbenv hooks into your shell
rbenv init is a helper command to bootstrap rbenv into a shell. This helper is part of the recommended installation instructions, but optional, as an advanced user can set up the following tasks manually. Here is what the command does when its output is eval'd:

Adds rbenv executable to PATH if necessary.

Prepends ~/.rbenv/shims directory to PATH. This is basically the only requirement for rbenv to function properly.

Installs shell completion for rbenv commands.

Regenerates rbenv shims. If this step slows down your shell startup, you can invoke rbenv init - with the --no-rehash flag.

Installs the "sh" dispatcher. This bit is also optional, but allows rbenv and plugins to change variables in your current shell, making commands like rbenv shell possible.

You can run rbenv init - for yourself to inspect the generated script.

Uninstalling rbenv The simplicity of rbenv makes it easy to temporarily disable it, or uninstall from the system.

To disable rbenv managing your Ruby versions, simply comment or remove the rbenv init line from your shell startup configuration. This will remove rbenv shims directory from PATH, and future invocations like ruby will execute the system Ruby version, bypassing rbenv completely.

While disabled, rbenv will still be accessible on the command line, but your Ruby apps won't be affected by version switching.

To completely uninstall rbenv, perform step (1) and then remove the rbenv root directory. This will delete all Ruby versions that were installed under rbenv root/versions/:

rm -rf "$(rbenv root)"

If you've installed rbenv using a package manager, as a final step perform the rbenv package removal:

Homebrew: brew uninstall rbenv

Debian, Ubuntu, and their derivatives: sudo apt purge rbenv Archlinux and its derivatives: sudo pacman -R rbenv