persuasion.markdown

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.

proposal.markdown

Ask any new Ruby developer what their favorite thing about Ruby is, and they'll inevitably mention the smooth experience of Rubygems. Initially created as a quick weekend hack, it quickly took the Ruby community by storm, and there are now more than 10,000 Ruby libraries packaged up as Rubygems.

This solution has worked for half a dozen years, and the basic approach will remain sound for years to come. As Ruby matures and the project comes under increasing usage, some wrinkles have appeared, both in using a large number of gems in a project such as a Rails application, and in how Ruby developers have historically created their packages.

In this talk, Yehuda will cover how the Gem bundler solves many of the problems involved in using Rubygems in large projects, including some of the details of how it works.

The bundler builds on the power of Rubygems to provide a standardized way for Ruby developers to include packages in their projects. It provides robust dependency resolution capabilities, which has been the missing link for seamless gem use. It also ensures a consistent development, staging and production environment, eliminating the effect of the system gem repository on those environments.

He will also demonstrate the practices gem authors can use when they create packages to mitigate some of these problems.

Finally, he will make some long-term proposals for the Rubygems system that will shore it up as it comes under increasing stress by the number of developers using it and the number of packages in use.