RubyGems have been exceptionally successful as a way for Ruby developers to share code. We generally think that sharing code is a good thing. Certainly, the Rails community can write projects exceptionally quickly; thanks, in part to RubyGems.
My beef has been that RubyGems doesn’t play nice with operating systems. We have standards for where things should live in any operating system. In the world I inhabit most (Unix systems), there’s a well defined place for everything. This is more than just being tidy. It helps keep things consistent and stable: when you install new software, dependencies can be easily found, for example.
Gems don’t really work like that. You can have many gem installations on your system, and they can all provide code to an application. It’s for this reason that the Debian team took the RubyGems code, modified it, and put it in a Debian package
. This helped bridge the worlds of Debian packages
(a packaging system that does dependency resolution to work out which packages you need in order to run the packages you want) and RubyGems (which mostly does the same thing).
Unfortunately this often lags behind the rapid development of RubyGems, so we’re forced to do things like install the newer version by hand over the top of the Debian version. This gets the job done, in doing so breaks the packaging system, which is a key reason that people use Debian or Ubuntu
. Think it’s just me complaining about this? Some other people who know a lot about operating systems aren’t happy either:
At least for Debian or Ubuntu users, there’s one solution: DebGem
. DebGem (from the guys
who brought you Phusion Passenger and Ruby Enterprise Edition) bundles RubyGems inside Debian packages. If each package has its dependencies declared right, you’ll be able to install any gem and it’s native dependencies, in one go.
I hope it works.
The issue here is that it takes lots of time to maintain packages. Especially when you’re trying to track the packages that come from an extremely prolific community that knows how to use distributed version control systems (git is now the VCS du jour for Rubyists). Let’s hope that Phusion can charge enough to make it worth their while to continue; once you’re hooked on this, it would be hard to stop.
Not sure that this really solves the problem. The core issue here is that the developers are elegantly solving the problem of how to reuse code as developers. Systems administrators are trying to make systems that are stable and easy to maintain. The two might never meet.
Final thoughts: they might do well pursuing a freelance model to get gems packaged. Also, a commercial distribution might buy it to gain market share. My fee for this idea is a snip at 10%.
( image from Ed Yourdon )