2007
12.23

There’s a “problem” with the current version of rubygems that’s causing somewhat of a FAQ, that as far as I can see, Google doesn’t index too well, so this post is for you, those people that find yourselves here via Google, at least until the problem is at least well known or the procedures change.

The relevant entry in the change log is this one:

Executable stubs can now be installed to match ruby’s name, so if ruby is installed as ‘ruby18’, foo_exec will be installed as ‘foo_exec18’

This can be found on Eric Hodels blog.

The current version of gems (1.0.1) installs the gem command as gem18 if your ruby is installed as ruby18.

For now, the fact that the upgrade via “gem update –system” is not doing anything with the old ‘gem’ command, is causing quite a few people to come into the ruby channel complaining about the following error:

gem:23: uninitialized constant Gem::Gem Runner (NameError)

You want to remove your old gem command (found at `which gem`) (i.e. rm `which gem`) and then link or copy the new gem command (likely gem18) to gem.

Anyway, this post is only this long so that it gains a high enough relevance for google to bother indexing it, with the goal of helping out a few of you folks until one of the many possible more permanent resolutions comes about.

Overall, the 1.0.1 release is a great release, seeing a lot of enhancements in rubygems that personally, I’m really happy to see. Thanks for all the hard work Eric, Chad and everyone else involved.

ttfn!

Update:

As it seems to have not been clear to some, on Debian, it may well (n.b. may well != will) be gem1.8, as your ruby may be ruby1.8.

If you need to know which it is, do the following:

ls -la `which ruby`

And this should tell you which ruby file you’re “ruby” is linked to, and where that link is located.

Share and Enjoy:
  • Print
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • HackerNews
  • LinkedIn
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter

5 comments so far

Add Your Comment
  1. thank you so much !!!!

  2. No, this is wrong. It installs it as gem1.8, not gem18… or at least on Debian 4.0 (Etch) it adds “1.8″ and not “18″.

  3. It is not “wrong”, please take a moment to understand the meaning of the word “likely” and the already posted quote from the changelog, which clearly explians how this works:

    Executable stubs can now be installed to match ruby’s name, so if ruby is installed as ‘ruby18’, foo_exec will be installed as ‘foo_exec18’

    Please see my updates on the original post for more information.

    You may also want to spend some time looking at the documentation for your distributions package management procedures and commonalities, as Debian, like several other distributions, does this, adding the version name to a binary in order to prevent version clobbers. This is very normal, but there is no ’standard’ for it, as such FreeBSD ports follows one procedure, Debian follows another, and sometimes you’ll find that even within a distribution the package maintainers (not the original software authors, or core distribution developers), do not keep the names consistent.

    A little time now could save you headaches in the future.

  4. for those of you running into this using deprec with ubuntu… i think this is the fix: http://forum.slicehost.com/comments.php?DiscussionID=1140&page=1#Item_5

  5. 1 Thanks!