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.
bq. “…it is basically impossible to patch them before compiling…”It actually works! But it’s incredibly ugly.In most cases, gems are just tarballs. Unpack ’em, patch ’em, repack ’em (in a pretty weird tar format, that is).Since there is no signing going on, noone complains (at least for now).But rubygems wouldn’t be rubygems if there wasn’t a catch. Some gems (like log4r) use a proprietary file format where tar can’t help you. :/But I guess that’s what we get for doing Ruby on a non-ubercool-everyone-uses-it-because-it-is-so-cool-and-it-is-the-only-thing-we-really-support (read: not OS X) system.
The biggestt advantage of RubyGems is that it has much more gems than portage and most of those are newer in RubyGems.
I fought with this problems in different areas too…There are a lot of such toolkit/language specific package mechanisms, like<ul><li>PHP/PEAR</li><li>Ruby/Gem</li><li>Python/Egg</li><li>Perl/CPAN</li><li>TeX/CTAN</li></ul>and probably a lot more, which I/we don’t know about yet.We can’t replace these systems, but we can use them to get a way better downstream experience and we can even make use of them in a cooperative cross-plattform/cross-distribution way.But this needs some work:<ul><li>A meta-layer, which abstracts the information of all these databases</li><li>Distribution/plattform specific tools, which translate this abstracted information into distribution/plattform specific commands/code/packages/whatever.</li><li>Replacing or at least disabling the language/toolkit-specific package managers (Gem, CPAN, PEAR, …) downstream in each distribution.</li><li>Adapting the workflow of each distribution to make use of this tools/information</li></ul>This isn’t something, which will be solved by tomorrow, but to keep up with the often really fast development of packages in this own ecosystems, we need to get this done by the day after tomorrow.This systems provide a lot of information, mostly even dependencies for each package – we should use this information!Regards, Elias P.
I still wonder why people _only_ pick on gems – deserved, or undeserved – but leave out the package manager of distribution XYZ.Am I the only one who sees a huge conflict of interest here? I mean php ruby python perl ALL have their own way to handle packages, but we also have every distribution use its OWN package/source manager (dpkg/aptitude, rpm, pacman, ebuilds etc.. etc..)