The Gist

My morning started out like most people's, as I sat down at my computer while eating a bacon-egg-and-cheese on an everything bagel. And then, like everyone's morning it quickly made a hard right turn in a different direction.

On the lookout for an fun open-source project to contribute to, I found myself on the Dev.to github repo. When looking into their documentation, I find that they're using something called..."Rbenv". Huh?!

Before we shove off port and start sailing towards gem covered seas, I do want to let you, my faithful crew, know that this article is going to explain what RVM is, then Rbenv, why either matter, and the process I had to undergo to successfully transition.

I've been watching too much, The Terror. The first seasons was good! The second season, not so much.

The Why

Okay, why are either of these package managers for Ruby relevant?

Well, firstly, here's a quick snippet on package-managers.

"A package manager or package-management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer's operating system in a consistent manner."

Option #1 -> RVM (ruby version manager)

RVM was mainly authored by Wayne Eseguin, and you can still find him on twitter maintaining RVM, along with other projects. Work on RVM first began in February, 2012.

RVM had a quick installation process, and one that didn't require a lot of spelunking into your files. It's great for those starting out, simple projects and all.

This isn't about one being better than the other, like any tech it's about weighing the pros and cons, aligning those with what it is that you're trying to achieve, and choosing what you want to use. Competing technologies can often co-exist and drive each other to improve in order to gain more users. RVM is great for what it is, but once you find yourself in larger companies you may start asking questions and looking into what's most efficient for your own work process.

Much of the gripe with RVM has to do with the weight of it's installation process.

Here's an extensive explanation, clarifying misinformation and filling in some gaps in what's said about RVM's 'cd' function.

A quick summary of the issue would be that, RVM creates a new function that hacks into the cd command to easily provide you with it's feature of switching Ruby versions automatically.

Who loves Hacker News? Well, here's a wonderful thread after Rbenv's first release, where it seems the whole of the Ruby community finally felt it had a safe space to let out years of pent up frustrations in one cathartic thread.

Here's the HackerNews post, titled:"Rbenv, an unobtrusive rvm replacement"

Here are some highlights from the thread

"With all due respect, ruby is a language, and rvm is a collection of really fragile and dangerous shell script hacks."

And another

"RVM is hardly development ready, imho. Every week I run into problems/confusion with the environment it creates and expects.
I would never put it anywhere near production."

And one last one

"The complete lack of a changelog doesn't help either. I never know whether something's going to break in a new release and almost every new release has some little semantic change that borks my system."

Now, for good posture I'll include some of the comments that were in support of RVM, that also highlight the reason why I would believe that most coding boot camps have added it into their curriculum.

Uno

I'll take your word for it. For me, it mostly saves me a bunch of time. Edit: Just in case I'm coming off as snarky here, I don't mean to. My projects tend to be on the simpler end, and rvm saves me a lot of time. I'm sure it's a little cowboyish for bigger projects - I was just wondering if there was something about rvm that made it universally inappropriate for production use. Double Edit: "a bunch" is probably an overstatement. rvm was a great help transitioning to 1.9.2. I'm not sure if it will provide much utility going forward.

...Dos

This is kind of a classic "fast, correct - choose one" debate. If saving time is more important, perhaps you should use RVM in production, if correctness is more important, you probably shouldn't. It comes down to how expensive your mistakes are.

...Tres

If you only have one server and can script most of the install process it's not a problem. When you have more than one server, rvm is not going to save you time.

Option #2 -> RBENV(ruby environment)

RBENV was authored by Sam Stephenson, who can be found on twitter. He's currently working at Basecamp. Work on RBENV first began in August, 2012.

A major pull of rbenv's it that it's lighter. And by that we mean that it doesn't have to throw as many hooks into your computer system.

Here's some of the highlights from their own github repo where the development team goes into comparing the two technologies and how they compare.

rbenv does…

• Provide support for specifying application-specific Ruby versions.
• Let you change the global Ruby version on a per-user basis.
• Allow you to override the Ruby version with an environment variable.

In contrast with RVM, rbenv does not…

• Need to be loaded into your shell. Instead, rbenv's shim approach works by adding a directory to your $PATH.
• Override shell commands like cd or require prompt hacks. That's dangerous and error-prone.
• Have a configuration file. There's nothing to configure except which version of Ruby you want to use.
• Install Ruby. You can build and install Ruby yourself, or use ruby-build to automate the process.
• Manage gemsets. Bundler is a better way to manage application dependencies. If you have projects that are not yet using Bundler you can install the rbenv-gemset plugin.
• Require changes to Ruby libraries for compatibility. The simplicity of rbenv means as long as it's in your $PATH, nothing else needs to know about it.

thanks rbenv!

Personally, at this point of doing my research I was pretty convinced that it was time to take an hour at most out of my day to clean RVM out of my system and run through RBENV's installation process.

But for the sake of education, I'll some info on the technicality behind how RBENV works.

1) you run a command, be it Ruby or Rake
2) your computer will then run through directories, looking for that particular executable.

/usr/local/bin:/usr/bin:/bin

3) There's an environment called PATH
4) this contains a list of directories that looks like the code above
5) Every directory is separated by a color, ':'
6) this process will occur left to right, have the object on the left take priority over whatever is left over to the right

1) rbenv inserts "shims" at the front of your PATH

~/.rbenv/shims:/usr/local/bin:/usr/bin:/bin

2) rbenv uses rehashing to maintain your commands in that directory
3) it them matches ruby commands across your system
4) these commands can range from irb, gem, rake, rails, to of course, ruby

The Where

The first thing you should worry about before swapping out one technology for another should be the packages that you've installed so far within that manager.

If you, like me, already had RVM installed cause that's the direction your boot camp took you in and you didn't want to stir the pot on day two of a daunting 3 months ahead...

Type into your terminal (hopefully BASH):

gem list --local

Then you'd get a list of gems that were installed on your local system:

*** LOCAL GEMS ***

actioncable (5.2.1, 5.0.7)
actionmailer (5.2.1, 5.0.7)
actionpack (5.2.1, 5.0.7)
actionview (5.2.1, 5.0.7)
active_model_serializers (0.10.7)
activejob (5.2.1, 5.0.7)
activemodel (5.2.1, 5.2.0, 5.0.7)
...
ETC!

Then, you'd want to copy this and paste it somewhere for you to reference later on. I don't know if there's a simpler way to export and import your gems into a new package manage like Rbenv, but I don't know it and it's already 11am! No time!

The next step would be choosing between two of the following RVM commands to remove the manager

1) rvm implode

2) gem uninstall rvm

Additionally, if you created special script calls check these places

The How

Alright! So I went ahead and used 'rvm implode' in my terminal, honestly due to just wanting it all gone in one go and reading this was the first command I should try.

I soon as I ran it though, I saw this:

my-local-machine-location.../.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/gems/compass-core-1.0.3/stylesheets: Permission denied

And so, these lines keep printing out, each ending with 'permission denied'.

After contol C-ing it I then got...

Failed to completely remove /Users/kurt/.rvm -- You will have to do so manually.

Fine. The hard way then.

Seems like when I first ran through the installation process I did it incorrectly, or at some point I moved the files.

And yes, you can also try running "rvm implode --force" flag. And before anyone start having a panic attack about forcing anything, it didn't work either.

Back to StackOverflow...

Eureka!
How Can I Remove RVM ruby version manager from my system?

And so I implemented the command that was most voted, and actually originally from RVM's own troubleshooting page.

How do I completely clean out all traces of RVM from my system, including for system wide installs?

Okay, below is the line I entered

/usr/bin/sudo rm -rf $HOME/.rvm $HOME/.rvmrc /etc/rvmrc /etc/profile.d/rvm.sh /usr/local/rvm /usr/local/bin/rvm

AND

/usr/bin/sudo /usr/sbin/groupdel rvm

AND

/bin/echo

AND

rm -rf /usr/local/rvm

When I ran my next calls, I got that no such file or directory exists.

sudo rm /etc/profile.d/rvm.h
sudo rm /etc/rvmrc
sudo rm ~/.rvmrc

I ran through some other removal commands to make sure that nothing remained, getting a response that RVM did not exist after each.

I then went into my local files, found refrences to RVM and commented them out for now.

• ~/.bashrc
• ~/.bash_profile
• ~/.profile
• ~/.zshrc
• ~/.zlogin

Once I start using RBENV and make sure nothing is badly broken, I'll go back and actually delete the lines. But what I've learned from experience is never get rid of something unless you've tested and made suer you don't need it anymore. Thus why I have around 50 tabs opne...

run the following command to check all of your hidden files

ls -a ~

Now time to install RBENV (:

This actually didn't take as long as expected.

Gotchas to remember:

• have Homebrew installed! This post is already mad long, so you can click the link and run through that.
• always restart your terminal after pasting in commands into your bash files. Even if you think you don't need it, just good to give it a clean start.

Helpful Links that also do a setup walk throughs:

• This gist from traumverloren
• Thoughtbot also uses rbenv
• DigitalOcean and their rbenv setup process

1) update homebrew

brew update

2) then install rbenv through homebrew

brew install rbenv

3) This part was a bit weird cause I thought it wasn't working. Go to your .bash_profile/.bashrc files and add in

export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)" 

If you're using ZSH, then just paste eval "$(rbenv init -)" into your .zshrc file

4) okay, here's where I borked myself. 'rbenv init' is only to print out instructions on how to integrate shell commands. Which is what we did in step 3. So when you read that, run it, and just get the same instructions, don't freak out.

5) run this to check that everything installed properly

curl -fsSL https://github.com/rbenv/rbenv-installer/raw/master/bin/rbenv-doctor | bash

And you should see something like

Checking for `rbenv' in PATH: /usr/local/bin/rbenv
Checking for rbenv shims in PATH: OK
Checking `rbenv install' support: /usr/local/bin/rbenv-install (ruby-build 20190828)
Counting installed Ruby versions: 1 versions
Checking RubyGems settings: OK
Auditing installed plugins: OK

YAY!

Okay now, let's see the ruby list

rbenv install -l

Annnnd let's install the latest. Make sure to check the latest version of Ruby on their site.

Then simply add in the default one you'd like to be available globally.

rbenv install 2.6.4 

Also, you're probably going to want to install the bundler to bundle and install gems

gem install bundler

TLDR;

I went through the what RVM and RBVENV were and looked at their pros and cons. It all boiled down to speed of getting things working versus quality. After which the second have of this post was dedicated to my own removal/installation steps. Hopefully this helps some people out there, I know it would have come in handy when I set out to do this. If it doesn't, there's always the internets and stackoverflow!

Credits:
unsplash: Charles 🇵🇭