A Day in the Life of Ruby Dependencies

Typical day as a Ruby developer:

1. Notice that guard gem processes are using 80%+ CPU (each) at idle. The version we are using is over a year old, and there have been many new versions since, so I decide to try upgrading the gem to see if that fixes it. I don’t want to upgrade to the latest version, because it is a different major version and there may be breaking changes. I decide to upgrade to the latest 1.x version.
2. Bundler doesn’t have a way to specify a version when updating a gem, so I modify the Gemfile to specify the version I want (1.8.3).
3. Run `bundle update guard`. Bundler downloads the source index from rubygems.org, which it does every time, and takes about half a minute. Then it attempts to resolve dependencies and install/update gems, which takes a few more minutes (depending on how many gems you’re using).
4. Bundler “resolves” dependencies by telling you that it can’t resolve dependencies. It turns out that many gems depend on specific, mutually-exclusive versions of the same gem, and the dependent version changes every time the parent gem is updated.
5. In this case the dependent gem is “listen”. Run `bundle update listen`. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies.
6. Failure: Bundler can’t update the listen gem because the guard gem has been locked to the old version. If this sounds like a circular problem, congratulations — welcome to Bundler hell!
7. Manually edit the Gemfile.lck file so that the guard gem uses the new version.
8. Run `bundle update listen`. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
9. Run `bundle update guard`. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
10. Failure: guard requires v1.3 of the listen gem. We are using v0.7.3.
11. Bundler says that the compass and sass gems both require old versions of the listen gem, despite the fact that the rubygems.org pages for compass and sass don’t mention listen.
12. Update the compass version in the Gemfile and run `bundle update compass`. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
13. Failure: Newest version of compass requires a newer version of rb-inotify.
14. Run `bundle update rb-inotify`. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
15. Failure: Cannot update compass, because it is locked to an older version. (Never mind that we specifically told Bundler to update rb-inotify — it’s going to try and update everything.)
16. Revert Gemfile change to compass.
17. Run `bundle update rb-inotify` again. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
18. Update the Gemfile again and run `bundle update compass` again. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
19. Failure: Newest version of compass requires a newer version of rb-fsevent.
20. Run `bundle update rb-fsevent`. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
21. Failure: Cannot update compass, because it is locked to an older version. (Never mind that we specifically told Bundler to update rb-fsevent — it’s going to try and update everything.)
22. Revert Gemfile change to compass.
23. Run `bundle update rb-fsevent` again. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
24. Update the Gemfile again and run `bundle update compass` again. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
25. Run `bundle update guard` again. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
26. Whoops — Bundler says Compass requires v1.1.x of the listen gem. (Again, I can’t find where that is specified anywhere.)  But guard 1.8.3 requires listen v1.3.x! Looks like another typical no-win situation.
27. Looking through the guard version log, I see that 1.8.2 only requires v1.0 or higher of the listen gem.
28. Set guard version in the Gemfile and Gemfile.lck to 1.8.2.
29. Run `bundle update guard` again. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
30. Failure: guard requires a newer version of the formatador gem.
31. Run `bundle update formatador`. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.
32. Run `bundle update guard` again. Bundler downloads the source index from rubygems.org and attempts to resolve dependencies. This takes a couple minutes.

There you go. Updating a single gem — something that should take less than five minutes — stretched out into over an hour. (BTW, upgrading guard did fix the CPU problem.)

If you’re like me, you’ll have a lot of time to wonder about this process:

• Why can’t Bundler automatically update dependencies?
• Why does Bundler stop as soon as it hits an incompatible gem (instead of showing all incompatible gems)?
• Why is rubygems.org so slow?
• Why can’t Bundler cache the source indexes?
• Why does Bundler constantly recommend running `bundle update`, when it’s common knowledge among Ruby developers that this is something you should never do?
• Why are gem authors setting dependencies to specific minor versions, sometimes at random?
• Why are gem authors introducing backward incompatibilities in minor versions?