Punctuated Productivity

I continue the quest to use the leopard provided ruby and gems. Unfortunately, I’ve made some mistakes. Perhaps I can save you from doing the same. Want to benefit from my experience without investing by reading the story? Skip to the recommended process at the end.

The Story

Part I: Anticipation

I upgraded to leopard recently. Before doing so I read about leopard’s new and improved ruby and rails support and some of the issues around this support. Since I had previously installed ruby and rails using Dan Benjamin’s excellent “Building Ruby, Rails, Subversion, Mongrel, and MySQL on Mac OS X” I anticipated that, at the least, I would need to make some adjustments when it was time to install or update gems so I wasn’t surprised when I got an error while running geminstaller on one of my projects. I’m not blaming geminstaller. I suspect the problem would have occurred if I had attempted my installation with a standard “sudo gem install” command.

Part II: Just Like I Had Good Sense

I decided to move forward by removing my installations of ruby and rubygems then using the leopard installation for future gem installs. The first step was to remove the installations of rubygems and ruby. Fortunately, I had saved the source directories that I used to install these features originally. To remove rubygems, I did the following:

$ cd /usr/local/src/rubygems-0.9.2
$ sudo rm `cat InstalledFiles`

This will remove the gem excutable, but not the gems themselves. I expected to remove the gem library when I removed my installation of ruby.To remove ruby I thought I could do something similar:

$ cd /usr/local/src/ruby-1.8.6
$ cat .installed.list | xargs -L 1 sudo rm -dfv

I ran that last command over and over again until it no longer deleted anything. I could have changed the rm command to ‘rm -rf’ but I wanted to see what got deleted. At some point I realized I was only deleting ‘ri’ stuff so it was time to do some more research.

Part III: The Awakening

Apparently you can specify an option when installing ruby from source to keep a list of all files installed. I didn’t know about this and didn’t do it. It would have been helpful.Instead I attempted to decipher the makefile to determine what gets done when you say ‘make install’. It turns out most of the work is done in a script called instruby.rb. I sifted through that script and attempted to devine where and what it moves into place when performing an install. I listed every directory and file, then removed the duplicates and came up with this set of commands for removing ruby:

sudo rm -rf /usr/local/lib/ruby
sudo rm /usr/local/bin/ruby
sudo rm /usr/local/bin/erb
sudo rm /usr/local/bin/irb
sudo rm /usr/local/bin/rdoc
sudo rm /usr/local/bin/ri
sudo rm /usr/local/bin/testrb
sudo rm /usr/local/share/man/man1/ruby.1

I expected that typing $ ruby -v would show the leopard version of ruby. Surprisingly, I saw something like “/usr/local/bin/ruby not found” (I don’t remember the exact message). Of course the issue was that the previous ruby had been hashed by the shell. Fixing it was simple: $ hash -r. Now I see:

$ ruby -vruby 1.8.6 (2007-06-07 patchlevel 36) [universal-darwin9.0]


Then I tried a few commands installed as gems. Here again there were errors. This time the solution was to remove the associated bin file from /usr/local/bin. At this point I realized that all gems with executables that I had previously installed had entries in /usr/local/bin that would likely generate errors.

Part IV: Drastic Measures

It was at this point I elected to remove the entire /usr/local and /opt/local directories. Keep in mind that I have a relatively new macbook and I can still fairly easily reinstall anything that I had previously removed from there.Now my gem installs are working correctly when I apply some of the new darwin solutions outlined below.

What would I do now, with the benefit of hindsight?

1. First, why change your existing ruby and gems installation? If it works, you’re done. Wait till the kinks are worked out before investing your time.
2. If you really want to use the leopard versions of ruby and rails, don’t install leopard… Not Yet!
3. Remove all of your existing gems, using “sudo gem uninstall [gem name here]. You don’t need them in their current location. Remove them first while you can use the gem utility. This will remove them both from the gem install directory and also from the /usr/local/bin directories (for gems that have bins).
4. Uninstall ruby using the commands listed above.
5. Now install leopard.
6. Update xcode from the leopard install disk.
7. Do not gem update --system (see this thread on apple’a ruby support discussion)

At this point you should be able to use rubygems to install and update gems in the new normal way. What’s that mean? I’ve encountered these issues:

1. The well documented architecture issue for some gems. Hint: try something like “sudo env ARCHFLAGS="-arch i386" gem install [gem name here]“.
2. The ‘gems’ command apparently attempts to update gems even when they don’t need updating. Why update a gem that doesn’t need updating? I don’t know, but if you try it will often fail with

Directory /Library/Ruby/Gems/1.8/doc/[some gem]/ri already exists, but it looks like it isn't an RDoc directory. Because RDoc doesn't want to risk destroying any of your existing files, you'll need to specify a different output directory name (using the --op option).

Try adding the “–no-rdoc” option.

If you see “missing ruby header files” when installing a gem then you probably missed the “install xcode” recommendation above.

This entry was posted on November 1, 2007 at 6:47 am and is filed under leopard, os-x, ruby, rubyonrails . You can follow any responses to this entry through the RSS 2.0 feed You can leave a response, or trackback from your own site.