Coincidentally, I'm sitting here staring at a terminal for the few hours because of RubyGems.<p>As a systems administrator, I'm absolutely not a fan of Ruby gems for exactly the reason the article mentions-<p>They're designed to be convenient for the developer, but they make an end-run around all of the methods that we admins set up to make things easy to deploy, and safe to update.<p>For instance- At Darkenedsky, we have a fleet of Ubuntu 6.06 webservers that are configured to run Apache, Postgresql, etc.<p>One of our coders has recently made a change which means that I need to push a library out to all 50+ machines..<p>Normally, this is a pretty trivial affair.<p><pre><code> for i in `cat hostlist`; do ssh $i apt-get install library; done
</code></pre>
Unfortunately, this particularly library is a Ruby gem, so things aren't nearly as simple ;(<p>The first step is that I need to ssh into each machine, and manually install Rubygems. Rubygems aren't packaged for Ubuntu 6.06, so I need to do a source install and configure.<p>Once it's installed, I need to update gems to have the most recent package definitions, and then I can start to install the package I actually want.<p>So far, it's annoying in that there are several extra steps, but they're scriptable, so it's liveable.<p>Unfortunately, installing the packages isn't very scriptable at all. When I install, I'm presented with a menu-<p><pre><code> Select which gem to install for your platform (i486-linux)
1. fastthread 1.0.1 (i386-mswin32)
2. fastthread 1.0.1 (ruby)
3. fastthread 1.0.1 (mswin32)
4. fastthread 1.0 (ruby)
5. fastthread 1.0 (mswin32)
6. Skip this gem
7. Cancel installation
</code></pre>
If this were a non-gems library, and/or packaged as a normal Ubuntu release, I wouldn't need to manually choose one of these. I could set my choice in debconf (write it to a file), and then push it out everywhere.<p>If we're dealing with only one machine, like most developers do, this isn't a big deal. It downloads and installs the gem, and you're good to go.
But when you're dealing with a fleet of machines, anything that requires manual interaction is a sin against man and god.<p>Debconf allows me to choose whatever level of interaction I want-<p><pre><code> "Ask me all details, even the trivial ones"
"Only ask me the important stuff"
"Use the choices provided in this file"
</code></pre>
Why should I need to choose between 1.01 and 1.0 after I start the install?<p>On Ubuntu, if the packages were really so important that both needed to be available, I could choose to install something between<p><pre><code> apt-get install ruby-fastthread-1.0
</code></pre>
or<p><pre><code> apt-get install ruby-fastthread-1.1
</code></pre>
Again, we're down to one command. Nice and simple, no interaction needed.<p>Further compounding the pain is that this isn't a choice I should even have to make- Why would I want the win32 version of a library on by Linux box?<p>If I'm installing a packaged version, It's already been tested in this configuration, and it's designed to work with everything else on the system.<p>Too many servers give me an error on install-<p><pre><code> Building native extensions. This could take a while...
ERROR: While executing gem ...
(Gem::Installer::ExtensionBuildError)
ERROR: Failed to build gem native extension.
</code></pre>
While that's certainly fixable, it means that I need to babysit the install far more than I do for something that's properly packaged.<p>After I choose what I want, I get to wait while the package downloads across the public internet.<p>When dealing with Ubuntu, all our servers are pointed at an in-house repository for packages- We keep a copy of everything we need on-site, and I can update it with one command.<p>This means that when installing software, it only has to travel to the server a few racks over, not out the internet at large. With gems, this system is broken- Each one reaches out to the public internet.<p>Not only is this is <i>much</i> slower, but I can't trust that a package is 100% identical.<p>Having one machine be different, even by a point release, can be a guge problem in trying to debug intermittent errors.<p>Finally, upgrading the packages are far more difficult that they have to be.<p>If a bug is discovered in a library, such as the zlib bug that came out a few years ago, I can update it trivially and easily across all the machines.<p>Ubuntu has built-in commands for updating security bugs, and it separates that from updating features.. That way, I don't need to move to the next version of a package, possibly breaking the code, to resolve a security bug.<p>Now, that's not to say that issues with Ruby gems couldn't be fixed.. I'm sure that one by one, they could be addressed- Scripting support could be beefed up, local repositories could be added. Upgrading could be improved, and configuration could be rewritten..<p>But even if they were to fix EVERYTHING on the list, it would still be layering one packaging system atop another, which means that we need to have two ways to do everything.<p>Two sets of config files.
Two repositories of packages.
Two places for bugs.<p>As the author suggests, the problem comes in that OS packages and Ruby gems are are focused on different audiences-<p>Developers love ruby gems because for the one machine they use to write the code, it's easy, fast, and convenient.<p>Admins hate gems because when you're trying to deal with a fleet of machines, it's none of the above.