Rails: followup

I received quite some comments on my rant about Ruby on Rails a few days ago; I guess I must have received some inbound link on a ruby-fanboy-website or some such. Most of it is just bashing me since, I'll admit, my post wasn't very constructive (and which according to my policy of only blocking spammers I've not moderated away), some of it just posits another opinion about packaging (which is valid), and one Eric Anderson gave a good and constructive set of arguments that I just have to reply to.

First of all, yes, I hate RubyGems more than I hate Ruby on Rails. However, Ruby on Rails is the major success story in the Ruby community, and the main reason why people use that language; it's not unfair to say that I won't use RoR because of RubyGems. But perhaps I should've been clearer.

Anyway.

Eric mentions that RubyGems "solves two problems that other packaging systems are not addressing": the ability to install two versions of the same library, and the ability to install a single package on multiple operating systems. Well, first of all, the latter one simply is not true. There's CPAN.pm, which does much the same thing as RubyGems; but much of CPAN can be easily turned into a Debian (or RPM, or whatnot) package. The few cases where it can't, you're usually dealing with a broken CPAN package, anyway. There are similar things for Python (egg), and, heck, even TeX (CTAN). The fact that other scripting languages have proper and working packaging systems only outlines that there really isn't an excuse for the horrors of RubyGems.

Second, the fact that you even need to be able to install multiple versions of a library really shows that there's a problem with your development ecosystem. C, Perl, and Python programmers are used to stable APIs, and prefer not to change their APIs all that much. Most packaging systems reflect that preference, and deal with incompatible API changes the way they should: as the exception, rather than the rule. The people in the Ruby ecosystem clearly have a different opinion on that, which probably results in the difference in packaging system requirements. Personally, I prefer the non-Ruby way—I'll leave the discussion about "what happens when you need to do an urgent security update of one of your libraries but the API has changed three times since you last looked at it and now the library update breaks your application" as an excercise to the reader.

In closing, I'd like to reply to this one sentence that Eric put in his comment:

And of course there is no reason software cannot start as a gem (for people close to the ruby community) but as it's popularity increases packages can be created that are more tightly integrated into the native package manager.

Well, in an ideal world, he'd be right: there would be no reason. Unfortunately, in the RubyGems world—which is far, far away from an ideal world—the fact is that packaging RubyGems in a sane way so that they'll integrate with the rest of a Debian system is simply impossible. You simply cannot currently go from a gem and create a package out of that, because of how gems are done. That, more than anything, was what I was objecting to.

I can understand that many Ruby developers do not care about this much; that they are used to RubyGems, and that they can geet anything they need using that system. However, they should understand that different people have different preferences, and that packages for systems other than RubyGems is going to be necessary if their software is to become popular beyond the select set of people who care enough about Ruby. I personally know of plenty of people (myself included) who prefer things to be installed as operating-system level packages on the Linux systems they install; and even if it's not your personal preference to do things that way, you should at the very least not stand in the way of those who do.