homebrew-base | Scientific formulae for the Homebrew package manager

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.

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.