Update: since Reddit an DZone picked this up, and people still look at this post and just this post, please also check my followup on RubyGems, thanks.
I’m obviously referring to Ruby Gems.
If you follow Debian developers blogs at Planet Debian, you probably already know that some of them are on a crusade against RubyGems. I happen to agree wholeheartedly with that.
While the idea behind gems is pretty cool to standardise installation of libraries among heterogeneous systems, it has one big drawback: it takes the control out of a system’s standardised package manager, like Portage, like apt-get, like yum, and so on. While certainly a non-system package manager might be better than no package manager at all, and thus saves the hordes of Ruby on Rails users from having to install all the dependencies by hand, it should really allow for proper packaging of the libraries through the distribution, rather than taking over entirely.
There are even more arguments against gems when it comes to source distributions like Gentoo; one nice thing that Gentoo allows developers and users alike to implement is checking and changing the code around, like applying custom patches, or checking for particular type of code we might not want to have on our system. This can be folded up in further QA checks or particular checks for known broken boilerplate code (a similar situation happens – or at least happened – on the Gentoo/FreBSD profile, where I added code to check for one particular piece of gnulib that would have caused known runtime errors). RubyGems take those features away.
Because of the way these features are implemented (with phases) and the way RubyGems can only get installed, it is basically impossible to patch them before compiling, check the sources after unpack for known broken or insecure code, and much worse it is impossible to properly implement the test features!
This is particularly nasty since, as I said in my previous post, the test feature already saved me from committing a broken ruby-prof into ~amd64 last week, thanks to the fact that I switched that ebuild from gem to tarball, installing it “by hand” on the ebuild, so that the src_test function could be properly implemented. This is probably the best reason for not using gems I can think of, but certainly not the only one.
You can add to that that gems always install the tests code rather than just using it during test and then leaving it a part, you can add that they all install in their own subtree not meshing well with the rest of the system, you can add that a copy of the gem is kept on the system as “cache”, but not in /var/cache a sone would expect it to be but in /usr/lib (and lib64 for multilib).
If you take for instance rake, that installs through gem on Gentoo, you can find, among other things, that there is a rake.1.gz file that contains rake’s man page. But it does not get installed because it’s part of the gem, rather than being handled through doman.
Now, all that has been written about gems is probably true of many other similar technologies, like Python Eggs or Maven, as far as I know, and it shouldn’t be taken as a critique of Ruby as a whole. Just to say, Ruby is my favourite language. It just needs to be more polished around and to work more closely with vendors (distributors) so that it gets seamless with the rest of the system.