DEV Community: Stefan Wrobel

Bundle Everything

Stefan Wrobel — Wed, 23 Aug 2023 23:47:31 +0000

or: how I learned to stop worrying and ditch gemsets for good

tl;dr

If you don't use gemsets and are just interested in my bundler flow, skip to the Bundler workflow section.

Background

In my previous post about switching from rvm to ruby-install and chruby, I mentioned that my primary motivation for switching away from rvm is runaway gemset disk usage:

$ rvm disk-usage gemsets
Gemsets Usage: 5.4G

I'm generally working on a bunch of different ruby projects at once, and like every good rvm user, I would create a new gemset when I started or cloned the project because ... well, that's what you do! But the problem is that there's no straightforward way to eliminate orphan gemsets when rming the project directory, and so you're left with 5.4GB of gemsets and you have no idea whether those are even relevant anymore.

Enter bundler, the tool that seems to become more and more magical with each version. You're probably already using bundler (if you aren't, WHAT?!) but letting it install into rvm's gemset folder hierarchy rather than directly into your project's directory. It's time to change that in just a few easy steps!

Inspired by Ryan McGeary's excellent "Vendor Everything" post from 2011, I set out to come up with my own bundler workflow.

Bundler workflow

I've configured bundler to install gems to my project's vendor/bundle directory. That way, if I remove the project directory, all of the gems that I've installed specifically for it are gone as well. No more hunting down orphaned gemsets.

bundle config --global path vendor/bundle

This tells bundler to install gems to vendor/bundle by default (rather than your global gem store). You can of course always install gems that you need globally (like bundler) by using gem install.

Rails 4+ will generate binstubs for rails, rake and bundle to bin/. With binstubs, you can run bin/rake instead of bundle exec rake, for example. If you want to make it really simple, just add ./bin to the front of your $PATH and your shell will always look there first. To generate binstubs for any other gems, like spring, just run bundle binstub <gemname> and it will create one in bin/ for you.

This is a little bit tricky with chruby because it always puts its gem bin directory at the front of $PATH so you need to add it in an after hook, which isn't officially supported. This is how I accomplished that with my zsh/chruby setup.

You'll also want to add the following line to your .gitignore if it isn't there already:

/vendor/bundle

Bonus points: parallelize bundler

First, make sure you update to bundler >= 1.5.0

If you're using Linux, run nproc. If you're using a Mac, run sysctl -n hw.ncpu. If you're using Windows, then god help you...

Take the output of that command and replace the X below with it. This will tell bundler to always spawn X number of processes to install gems in parallel. Your bundle install runs will be much faster.

bundle config --global jobs X

rvm implode

Stefan Wrobel — Wed, 23 Aug 2023 23:44:03 +0000

tl;dr

rvm implode && brew install chruby && brew install ruby-install

Intro

As a ruby developer, I grew to love rvm. It does so much it seems like magic ... in fact, it may actually be magic. But after a multi-year love affair, its flaws became apparent.

$ rvm disk-usage gemsets
Gemsets Usage: 5.4G

Yikes. My first thought was to try to figure out how much disk space each individual gemset was using and remove some of them. I read the docs and didn't find anything there, so I went to the mailing list, and mpapis, being the amazing guy that he is, got back to me right away. Alas, no simple way to do this.

Then I started to think a little bit more about why I was even using gemsets. Typing bundle exec can get pretty annoying, but it isn't the end of the world. I had a separate gemset for each app to keep my gem dependencies from conflicting, but that's what bundler is for. What really annoyed me was that when I would rm -rf an app's code, I'd forget to remove the gemset and I had a bunch of orphaned gemsets out there hogging disk space.

rvm implode

The many talents of rvm

Like I mentioned, rvm does a lot:

Compilation/installation of rubies
Switching between rubies
Separation of gem dependencies

The problem is that it's trying to be all things to all people. There are some 20,000 lines of shell script in rvm, and each of these things can be accomplished much more efficiently by a single purpose-built tool.

1. s/rvm/ruby-install

brew install ruby-install

For installing rubies, I'm using ruby-install, written by the amazing postmodern. There's also ruby-build which works almost as well, but I love the fact that ruby-install lets me use shortcuts like I did with rvm so I can just do ruby-install ruby 2.0 and get the latest 2.0 patchlevel rather than having to specify manually like with ruby-build.

ruby-install is dead-simple and does exactly what it promises. By default it installs rubies to ~/.rubies although you can install them wherever your heart desires. I stuck with the default.

2. s/rvm/chruby

brew install chruby

For switching rubies, I'm using chruby, again, by the unstoppable postmodern. Some folks prefer rbenv, but I love the simplicity of chruby. Plus, it (optionally) does auto-switching like rvm, so if a directory has a .ruby-version file, it will switch to that version automagically.

chruby will automatically look in ~/.rubies, where ruby-install puts them, so no configuration needed there. just add three lines to your .bashrc or .zshrc:

source /usr/local/opt/chruby/share/chruby/chruby.sh # mandatory
source /usr/local/opt/chruby/share/chruby/auto.sh # if you want auto-switching
chruby ruby-2.0 # to set a default ruby