The point of this talk is to wrap up a number of ostensibly separate Rubygems-related issues under a unified banner.
First, I plan to lay out what makes Rubygems great, and why it’s a crown jewel of the Ruby ecosystem.
Next, I’ll show how Rubygems behaves under extreme stress, specifically showing how Merb’s extensive use of gem dependencies produced a breaking point that we had to solve in order to continue using Rubygems.
There were two major problems.
-
Dependency Resolution: When multiple gems depend on overlapping versions of the same gems, it’s very easy to get into a situation that Rubygems’ simple linear dependency resolution cannot handle. This has gotten worse over time in Rails, and reached a breaking point in Merb.
-
System Gem Complications: Rubygems is designed to work out of the system gems, which has led to complications where gems installed on a local machine produced subtly different behavior on a different machine (or production).
Once I lay out the problem, I’ll show our solution for Rails 3 that combines robust non-linear dependency resolution and storing Rubygems in your application. I’ll describe some of the roadblocks we encountered, such as native gems and gems that depended on specific behavior of the Rubygems runtime, and how we worked around it. I’ll also show how we were able to use Rubygems for installation, but make it possible to run the application without the Rubygems runtime.
Now that I’ll have explained how we worked around a number of problems in existing gems in the bundler, I’ll present some guidelines for packages Rubygems without those problems, so we can have a future without the need for these hacks.
Finally, I’ll present some proposals for Rubygems 2.0: what we can do to build on the great user experience of the current Rubygems and still accommodate the rapidly growing Ruby ecosystem and evolving packaging needs.