The magic of `bundle show` for debugging
One of the most handy things I’ve learned this year is how to make this bundler command work for me when debugging.
bundle show is a bundler command that can:
- Show the gems in your bundle or
- If given a specific gem name, show the path to that gem
See its documentation for more details.
In a small Ruby project I’m working on (while reading Noah Gibbs’ book Rebuilding Rails), for example, I’d see something like this if I called it without a gem name:
$ bundle show Gems included by the bundle: * bundler (2.3.7) * diff-lcs (1.5.0) * rack (2.2.4) * rack-test (2.0.2) * rake (12.3.3) * rspec (3.11.0) * rspec-core (3.11.0) * rspec-expectations (3.11.1) * rspec-mocks (3.11.1) * rspec-support (3.11.1) * rulers (0.0.1)
Where I find it most useful is for debugging, though, is calling it with a specific gem name:
$ bundle show rack /Users/amyhenning/.rvm/gems/ruby-3.1.2/gems/rack-2.2.4
How do I use it when debugging?
I do a lot of work on Ruby libraries at my job. Sometimes, I need to dig into third-party gems’ code to understand how to integrate with them (or to better understand bugs!).
The neat thing someone showed me about
bundle show <gem_name> is calling it as part of a command to open up a project in your text editor of choice. (This assumes you have CLIs installed for opening up said editor. For instance, VS Code can be opened up with
code; Sublime’s equivalent can be installed like so.)
# Opening in VS Code $ code $(bundle show rack) # Opening in Sublime $ subl $(bundle show rack)
In the above examples, the
rack source code located at the path specified by
bundle show rack will open up in the respective editor.
There are certainly other ways of looking at gem source code, but I think this is my favorite. The command is succinct and easy to recall, and I really like being able to read through gem code in an editor. I find it easier to navigate than going through Github, especially since this way shows me exactly which version I’m using.
The best part, though, is being able to put debug statements throughout the gem code to better understand how it works, then running whatever it is I’m working on - whether it’s debugging failing tests, figuring out why a tiny Rack app is failing to start, or something else. Because I’ve opened up my local installation of a given gem, any local project that depends on that gem will include my modifications. I inspected a bunch of variables in the
rack gem yesterday to understand an error that wasn’t mentioned in the book I’m reading, which helped me discover that Ruby (as of v3.0) doesn’t ship with WEBrick anymore!
Another bundler nicety is
bundle pristine (docs). When I’m done inspecting / debugging / generally poking around in gem code, I don’t want to be stuck with a ton of
binding.prys everywhere. An easy way to clean up
rack, for instance, would be via running:
$ bundle pristine rack
It feels pretty cool to look into gem source code. When I first started programming, gems kind of felt like black boxes that I just had to accept as they were. It was empowering learn these tricks - doing so has helped me better understand how the things I’m building actually work.