I’ve been responsible for enough technocentric, user-hostile interfaces in my time to know one when I see one, and RubyGems’s gem utility is a classic of the genre: it’s influenced by implementation details rather than end-user usage patterns, and it manages to frustrate me every time I have to deal with it. Here’s a real-life transcript that demonstrates some of the issues:

~ % sudo gem install mongrel
Select which gem to install for your platform (i686-darwin8.8.1)
 1. mongrel 1.0.1 (mswin32)
 2. mongrel 1.0.1 (ruby)
 3. mongrel 1.0 (mswin32)
 4. mongrel 1.0 (ruby)
 5. Skip this gem
 6. Cancel installation
> 2
Install required dependency daemons? [Yn]
Install required dependency fastthread? [Yn]
Select which gem to install for your platform (i686-darwin8.8.1)
 1. fastthread 1.0 (ruby)
 2. fastthread 1.0 (mswin32)
 3. fastthread 0.6.4.1 (mswin32)
 4. fastthread 0.6.4.1 (ruby)
 5. Skip this gem
 6. Cancel installation
> 1

1. Why am I asked whether I want to install an old version? Why would I want to do that? That’s the unusual case: the default behaviour should just be to install the latest version.
2. Why are the platform orders randomly switched? mswin32 is the first choice for mongrel, but the second choice for fastthread. That invites mistakes.
3. For that matter, why am I even being given the option of a mswin32 version? It won’t work. There is only one viable choice of platform. Don’t give me invalid choices.
4. What does ruby mean as a platform, anyway? I’d assume that it means a pure Ruby version, but it doesn’t.
5. Why must I babysit dependency fulfilment? I know that I have the choice of passing a command-line option (-y) to follow all dependencies, but I’d like to retain a bit of control. If there are required dependencies, I have two sensible options: install all the required dependencies and the requested package; or cancel the whole operation. How about just showing me all the required dependencies at once and asking whether I want to proceed or cancel?

I’m sure that these issues could be fixed, and probably quite easily, by someone who’s familiar with the internal workings of RubyGems. I’m not, and I also think that it’s helpful if user interface is directed by people who aren’t involved in the development side, so I’m just going to throw this criticism out there for the moment.