SlimGems, a drop-in replacement for RubyGems
A couple weeks ago, prior to RailsConf, I started working with a few others to fix some major issues with the RubyGems 1.8.x releases that were breaking or otherwise incapacitating tons of libraries (full disclosure, the list of broken libraries included some that I maintain). It was being made fairly clear during that week that there was a lot of dissatisfaction over the way the RubyGems project was being run. Our goal was simple: to create a fork of RubyGems that would provide the same (and more) improvements that RubyGems does, but with a strong focus on maintaining backwards compatibility and API stability over a much longer period of time, in order to ease the pain that library maintainers (and users) were being quite vocal about. The project was called SlimGems, and was leaked on Twitter by someone (you know who you are!) at RailsConf. Unfortunately, when it was leaked, we were not yet ready to release. We were trying to see if it was worth it to “fork”, and were still talking to lots of people to get insight into what other avenues we could take to solve the problem. We also wanted to make sure that things worked smoothly, so we were still testing and making adjustments. Everything works now, though.
Since then, lots has happened, some for the better, some for the worse, but I still think the SlimGems project is worthwhile to users, and focuses on a process that the RubyGems team is still not committing to. To give the RubyGems team and Gregory Brown credit, things have gotten better since early May. They have released a few new updates that silence the deprecation warning that caused much of the outcry. But the effort is still lacking in real substance. The RubyGems team has still not stepped in to commit to a stable API based on what library maintainers are currently using. This is getting more important as we draw near to the Ruby 1.9.3 release, which is potentially going to include RubyGems 1.8.x. If it does, many existing libraries will be broken outright in out-of-the-box installations, forcing library developers to update their libraries on RubyGems’ release schedule, or face many users complaining that their library does not work in a fresh Ruby install.
Today I am officially announcing the release of SlimGems (1.3.8). You can finally install the library via a
gem install slimgems. If you don’t like it,
gem uninstall slimgems!
Check out the site: http://slimgems.github.com
Why a fork?
Some people have raised concerns that a fork would cause an unnecessary fracturing of the community. I think we need to realize that SlimGems is not causing the fracturing. Many users are still “stuck” on RubyGems 1.3.7 for a variety of reasons, mostly involving incompatible API changes that their dependencies rely on. Heroku is still using 1.3.7 on their servers due to incompatibilities and upgrading issues. I think we need to have a way for these users to move forward in a responsible way, without the pain of breaking code.
One of the major goals of SlimGems is to maintain API compatibility with 1.3.7 (we forked from 1.3.7). We believe that this is absolutely possible while still being able to improve functionality and fix bugs. We’ve already done it—backporting tons of performance improvements and fixes up until 1.5.2. In doing so, we didn’t need to change a single API (unlike RubyGems, which changed many between these versions). While it may seem a little crufty to cling to old APIs, I’d like to believe that major infrastructure projects like RubyGems need to follow different rules when it comes to API agility. Too many libraries have come to depend on its functionality, and therefore changing the APIs would be extremely frustrating to the library developers put in so much effort to make things work.
We want to create a responsible process surrounding development of new features and refactorings. That hasn’t happened, and we’re a little unsure if it will. You can decide if you want a stable API or a cutting edge one.
But ultimately, forks allow users choice. Forking shouldn’t be considered an act of war. They are simply an act of choice. Good things came of all of the forks I can remember (I consider merb and gemcutter to be two), so this is an opportunity for improvement.
How Can You Move Forward with Ugly Code?
Remember, old APIs do not mean we can’t improve internals, or even add new amazing APIs! It just means what works now will work tomorrow and the day after. It’s easy to add functionality, and we certainly have a few ideas on what can be improved:
- A better, more efficient Gem install process that doesn’t need to build documentation locally.
- Tighter integration with Bundler’s functionality and dependency resolution. We want to end up in a place where SlimGems can basically be Bundler, and we would work with the Bundler guys to make this happen (they have been receptive to this idea).