Switching from RVM to chruby
I switched from RVM to Chruby last week. The switch was mostly smooth. I’ll write more about that after I go into why I made the switch.
A few years late to the boat
A few years ago,
rbenv came out and Hacker News threads were flaming with
opinions about how gross RVM is. It does so much. It rewrites
other basic bash commands. That may have changed in years since, but it never
I decided to keep RVM on my system. In the following years, I worked at a consultancy. They wiped systems clean between projects. I had the chance to try out rbenv instead of RVM (also because one of my teammates was quite insistent).
I was quite surprised. It felt like practically the same thing, in a
good way. Oh, but it did require this weird
rbenv rehash command every now
and then. I didn’t quite understand, but I had to deal with it after updating
After leaving that consulting job, I did some development for fun. I was back on an RVM install on my system. I used RVM less than other Ruby version managers at this point, but it still worked for me. That is, until I started trying to install new versions of Ruby.
Last fall, I tried installing a new version of Ruby 2.2.x, as I wanted to stay up to date. It was unavailable to install via RVM natively. Maybe RVM was out of date. I updated it…still nothing. Strike one.
Ruby 2.3.0 came out last Christmas. It was supposed to have string constants and other performance improvements. I wanted to give it a try. I ran into the same problem. Fine. RVM was a buzzkill, but it was still doing its job. I guess.
When I got my current job doing support with CircleCI in February, I started
seeing our Rails customers’ problems and I wanted to reproduce them. Sometimes
they used Ruby 2.3.0. Two or three months after it came out…it was still
RVM failed to make new Ruby versions available to me via
rvm list known.
Sure, I could look up the URL and install it that way, but I thought RVM
is supposed to manage language dependencies for me. In my mind, that includes
installing and switching. It was getting in the way of my development
exploration because it wasn’t keeping up. With that, I changed my mind about
RVM doing too much.
The uninstall of RVM was completely smooth. The install of
ruby-install were also smooth. I simply installed them via homebrew.
I spent a bit of time re-configuring my Bash prompt. This is what it looks like now:
|ruby 2.3.0 Erics-laptop:~/Dropbox/code/ruby/eric-hu-homepage erichu (master) $|
That’s pretty close to what it was when I had RVM installed. I set it with this line in my .bash_profile:
|export PS1="\[$(tput setaf 1)\]\$RUBY_ENGINE \$RUBY_VERSION\[$(tput sgr0)\] $PS1"|
No gemsets: a baseless fear
Having no gemsets was my biggest concern prior to my switch. Now that they’re gone, here are my thoughts:
I thought I would have duplicate gems installed in different locations:
<app>/vendor/bundle for each project. On double checking, I found I
was wrong. It’s installed at
(current Ruby version)/gems, so gems are
shared in a sane way. For example:
|ruby 2.3.0 Erics-laptop:~/Dropbox/code/ruby/eric-hu-homepage erichu (master) $ bundle show sass /Users/erichu/.gem/ruby/2.3.0/gems/sass-3.4.22 ruby 2.3.0 Erics-laptop:~/Dropbox/code/ruby/eric-hu-homepage erichu (master) $ bundle show activesupport /Users/erichu/.gem/ruby/2.3.0/gems/activesupport-4.2.6|
Two projects needing the same version of the same gem under the same Ruby will share the installation.
Hiccup: A Weird Warning
I had a moment of confusion while writing this post. It was a quirky error
middleman --help. I wasn’t sure if it’s just middleman or something
|WARN: Unresolved specs during Gem::Specification.reset: mime-types (>= 1.16) activesupport (>= 3.1, ~> 4.1) WARN: Clearing out unresolved specs. Please report a bug if this causes problems. Tasks: middleman article TITLE # Create a new blog article middleman build [options] # Builds the static site for deployment ...|
OH WAIT A MINUTE:
bundle exec middleman --help
|ruby 2.3.0 Erics-laptop:~/Dropbox/code/ruby/eric-hu-homepage erichu (master) $ bundle exec middleman --help Tasks: middleman article TITLE # Create a new blog article middleman build [options] # Builds the static site for deployment ...|
Ah ha. Muscle memory. I’m used to typing Ruby executables without prepending
Is it better to type this launcher command out? I type more and am constantly
reminded I’m running executables installed from different contexts. The
reminder is a good thing. I have to be deliberate about what I want, so
there’s less to go wrong and less to debug. Additionally, I’ve had
be='bundle exec' in my
.bash_profile since my first year of writing Ruby.
I’ve never seen a need to delete it.
On installing chruby, I saw that there’s some plugin to make
unnecessary. I think it was chdir, and I think I decided I would install it
when I needed it.
Now that I’m working without it, I like having less magic in my workflow. It’s
possible that one day I’ll want to install chdir to get rid of prepending
bundle exec, but Ruby also has a different place in my development life now.
Ruby is now my pocketknife language. It’s my general purpose tool, but I don’t expect to code in it daily anymore. A little bit less magic seems safer, albeit less convenient.
Hiccup: Mysterious behavior outside of home folder
My prompt has been acting weird here and there. The one time I consistently see something unexpected is when I execute commands outside of my home folder. On top of that, there seems to be a one command lag. Take a look:
|Erics-laptop:/tmp erichu $ cd ~ Erics-laptop:~ erichu $ pwd /Users/erichu ruby 2.3.0 Erics-laptop:~ erichu $ cd .. ruby 2.3.0 Erics-laptop:/Users erichu $ pwd /Users Erics-laptop:/Users erichu $ cd .. Erics-laptop:/ erichu $ pwd / Erics-laptop:/ erichu $ cd ~/Dropbox/ Erics-laptop:~/Dropbox erichu $ pwd /Users/erichu/Dropbox ruby 2.3.0 Erics-laptop:~/Dropbox erichu $|
I’m thinking this is a misuse of chruby’s
except on the Github homepage, this is listed under features:
Additionally sets $RUBYROOT, $RUBYENGINE, $RUBYVERSION and $GEMROOT.
You’ll also notice that there’s a lag in the change in prompt. When I change
$RUBY_VERSION environment variable isn’t set until I run a
command. This is also mysterious. I’ve tried another approach, using
$(ruby -v) piped into grep, but that has a similar one-command lag.
I’ve decided this is just a minor nuisance, and maybe I’ll be able to figure it out with some yak shaving one day. Overall, I’m happy with chruby and am willing to deal with the hiccups, for now.