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.
What is bundle show?
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!
Cleaning up
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 puts or binding.prys everywhere. An easy way to clean up rack, for instance, would be via running:
$ bundle pristine rack
Conclusion
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.