RubyGems for Debugging: What’s Up With That?

Ruby libraries (“Ruby Gems”) are awesome: the variety of them, the power of the best gems, how easy they are to install and debug… Few would disagree that RubyGems are among the very best features of Ruby, and one of the best reasons to use it for a project.

The Bundler is a welcome boost to Ruby Gems — declare what gems you use so that you can easily install them for a project. It also makes sure when you run it that you don’t use any undeclared gems. That way, somebody who installs gems via the Bundler can be sure that they have all the gems they need. It even makes sure they get the same versions of everything that you used.

Bundler was written for Rails 3, and has become so standard so quickly that a later version is being merged into RubyGems itself, and thus into the main Ruby distribution.

Bundler: Enemy of Debugging

Unfortunately, sometimes you want to add a gem that doesn’t necessarily belong in your list of gems.

There are great debugging gems out there: Pry, Rack MiniProfiler and the IRB utility belt are all great debugging gems, but you don’t necessarily want them all the time.

But with Bundler, you have to know your list of gems ahead of time. It’s just not easy to stop, decide that you need a debugger, profiler or console and then load it. Bundler acts like a bouncer — “you’re not on the list, buddy!” — even if it’s installed on your system.


(Photo from WikiMedia)

Jailbreak Your Irb

I’m not the first to notice this problem. The pry-debundle gem is one solution. Once you start pry, this gem will allow you to “debundle” (a.k.a. “jailbreak”) your Bundler environment, allowing you to use other gems you may have installed even if they’re not in the Gemfile. Doing that only in debug mode is just about perfect… If you make sure you have pry installed in every Gemfile you ever use, of course.

The Bundler folks have been notified of this problem long ago, but don’t really have a solution to it. The solution I know of being proposed was closed by the Bundler team as “won’t fix” — they feel that having more ways to allow not-declared-locally gems is only going to make production Bundler bugs harder to diagnose, which is true.


(Jailbreak! Photo by Falashad, CC by 2.0)

But What Can I Do?

There are obvious hacks around this. For instance, the Gemfile and Gemspec are just run as Ruby, so you can have them load a file from your home directory (perhaps called $HOME/.global_gemfile?), then put your debug gems in there.

You’ll have to modify every Gemfile you do that with, though…

Basically, there’s no current full solution to this. But if you’re aware of the problem, you can use a hack… And if you know about the hacks, you’ll recognize them when somebody inadvertently checks one in.

Knowing is half the battle!

2 Responses to “RubyGems for Debugging: What’s Up With That?”

  1. Soulcutter Says:

    For developing libraries you typically should not commit your Gemfile.lock, and so calling eval on a File within your Gemfile is fair game. It’s not a strategy you want to take if you DO commit your Gemfile.lock, however, since the lock file will pick up differences in your local bundle and lead to tons of headaches.

    • True. Unfortunately, it doesn’t work with applications or libraries that are already installed. But yes, sometimes you can do that!

So what do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: