A solution to broken Gems?

@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:

<ul>
<li>there are gems that don't have a matching ebuild</li>
<li>people still use gems direct</li>
<li>gem still need to compile native code == dependency issues</li>
</ul>

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

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).

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.

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.

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.

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.

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.

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.).