A solution to broken Gems?

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 )

9 thoughts on “A solution to broken Gems?

  1. Evgeny says:

    The issue with gems is that its such a damn complex system. It’s almost as complex as the systems used by OS, like rpm/dpkg/etc…

    Thats why there are projects like newgem, and hoe, that make the problem even worse – because now to build gem X I also need to have gem “hoe” installed.

    The rubygems code is too long to be reliable, thats why it “breaks” every other version. There is just too much of it.

    I have long since stopped hoping that the environment where my application will run will have any of the gems the application depends on, and I just put them inline into the application in a vendor/ folder. It’s quite easy to manage with git submodules, and a very short script to build the code (for binary ext) can be part of the installation.

    While it is nice to have all the “gems” already installed for you, rubygems makes it a huge PITA. And all kinds of problems creep up, especially when you have more than one version of a gem on the system (yes, that is possible, and stupid, yes.).

  2. Evgeny says:

    Oh, and say that I did trust the host and deployed an application depending on the gems installed in that system … who says they wont be just uninstalled or replaced with incorrect versions without any notification for the applications using them?

    Someone might want to just “upgdate” the system gems – and now the applications break.

    Thanks, I’ll rather have my own bundled in and not rely on something that breaks my application because of external influence.

  3. bob says:

    I thought the point of the Phusion debgen stuff was that they had worked out a way to automagically produce the debs from gems. By charging for repo access their are monetizing that not the effort to package gems manually.

    What mostly annoys me about gems is the split between github and rubyforge. Coming from a perl world where everything is in one place its really annoying.

    Having said that gem 1.3 does suck a lot less than 1.1 for dealing with that.

  4. Brandon says:

    I think that Evgeny points out where we are going: github. All of our projects have started to include everything in the vendor/plugin directory – because it is far easier and more portable.

  5. Eric R Hodel says:

    Hi, I’m the RubyGems maintainer.

    While you allege there are standards for where things live, I have yet to see anybody give chapter and verse for these things. Nobody has offered patches to “fix” this “problem” that RubyGems is supposed to have. I’ve been complained at enough that I’m not motivated to actively try to fix this problem. Somebody needs to move their fingers from their blogging tool to their editor, check out RubyGems and get working.

    Neil Wilson worked with me to improve how RubyGems behaves in Ubuntu and Debian, unfortunately it seems they want to look a gift horse in the mouth.

    Neil’s problems getting his work accepted leads me to believe that it doesn’t matter what I do for RubyGems as it will always be wrong in the eyes of Debian and Ubuntu people.

    Furthermore, I added a file that any OS-based distribution of RubyGems could add that RubyGems would require (rubygems/defaults/operating_system.rb) in order to improve the update problem. In theory, Debian and Ubuntu should be able to throw their changes into this file in their RubyGems distribution and any time a user manually updates RubyGems it will continue to Just Work. Both JRuby and Rubinius use this feature to add their own customizations.

    I’ve just looked, and Debian isn’t using this and I’m not sure why. Perhaps they don’t read my release notes (third new feature).

    As far as I know, nobody claiming to be the Debian-RubyGems maintainer has ever posted anything to the mailing list (the maintainer appears to be daigo@debian.org, but there’s no such address subscribed to the mailing list).

    There was a time when I cared about making RubyGems not be “broken”, but the more I thought about it the more I found it was a giant political sink-hole.

  6. simpsonjulian says:

    Flipping ‘eck. Thanks for the comments everyone. I just replied via email to Eric. This needs fixing. Seems no-one is happy with this situation.

  7. hosiawak says:

    The title of this article should say: “A solution to broken Debian/Ubuntu” and the answer should be: “Just use Gentoo” (or a dozen other distros that don’t use a packaging system that for some reason doesn’t play nicely with Rubygems).

  8. simpsonjulian says:

    @hosiawak: I’m not up on the Rubygems implementation in Gentoo. I’ve used Gentoo on my own machines in the past. Our EngineYard machines use Gentoo. I’d still prefer to use Debian/Ubuntu. That’s my personal taste.

    anyway, I had a quick Google. It doesn’t seem that the Gentoo situation is much different (based on this:

    there are gems that don’t have a matching ebuild
    people still use gems direct
    gem still need to compile native code == dependency issues

    Things may be a little better on Gentoo, but I wouldn’t say it’s a problem solved.

    The title of the post was referring to the disconnect between rubygems and debian, but also the things that gems do that aren’t really suitable in a production setting. Like gem update –system

  9. […] was a post about DebGem:A solution to broken Gems? I’m not sure it took off. I’m not done on this subject and I think there’s more […]

Comments are closed.

%d bloggers like this: