Ruby bugs on Leopard

I installed Leopard about 2 weeks ago and been doing Ruby on Rails development on it since. I encountered some bugs initially, but I managed to conquer them. I think Leopard’s great for doing RoR development. It seems faster, it seems more polished, its just very pleasant to do work in.

Here’s what I learned though about Ruby in Leopard:

1. Don’t update rubygems. It’s already up-to-date (at least as of this writing.) If you do a “gem update –system” on Leopard, you will be sorry. Because you’ll suddenly break the careful packaging Apple has done with Ruby and reduce the 20 or so gems (not sure the exact count) available down to 0.

There’s a simple fix for this though – what happens is that the places where it looks for your gems gets mixed up. What you need to do is go into your ~/.bash_profile and enter in:

export GEM_HOME=/Library/Ruby/Gems/1.8
export GEM_PATH=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

Then do a

source ~/.bash_profile

The reason why this fixes it is that GEM_PATH now points to the place where Apple put all the system-provided gems. GEM_HOME points to where Apple originally set to where you install gems. Note that GEM_PATH is “read-only” whereas GEM_HOME Is “read-write” by rubygems. Oh and if you do this, you can safely update rubygems. :)

2. rcov is broken, but you can fix it.

For some reason, rcov out of the box will include some of its own classes in the reports when profiling functional tests on Leopard. This throws off the coverage statistics.

The fix for this is to include “#{ENV[‘GEM_HOME’]}” in the rcov exclusions parameter –exclude.

3. rcov reports don’t show up colorized in Safari 3.

Now once you’ve got rcov working, when you click on a class to see what lines are covered and which aren’t, you find out that you can’t on Leopard. Well that’s not exactly right. It turns out that its Safari 3. I also tested it out with the latest WebKit nightlies – its broken too. I looked into this and found that some old rcov 0.4 reports on the web render fine, but the newer rcov 0.8 ones don’t. It seems Safari 3 doesn’t like some of the internal anchor tags.

The workaround for this is to use any other browser for viewing your rcov reports on Leopard. If you’re using Firebug, you might as well use Firefox. Otherwise, Camino is good. Or if you’re the power user type, OmniWeb. Cutting edge – Shiira. I could go on and on – I’m a browser fanatic. Did I mention Flock?

Anyways… Ruby development on Leopard is actually quite good. These 3 bugs were not that big a deal. I think its great that Leopard ships with all sorts of Ruby goodness built right in. And I didn’t even mention RubyCocoa or anything like that.

Any other tips for Ruby development on Leopard? Let me know via a comment!

21 Replies to “Ruby bugs on Leopard”

  1. Hi there,

    It’d be great if you could file a bug report about Safari on Leopard not correctly rendering the rcov output. The bug reporting interface for WebKit is available at http://webkit.org/new-bug and attaching a sample file that demonstrates the problem should make it super-easy to fix it. The fact that OmniWeb apparently renders it fine even helps narrow down when the problem was introduced, as OmniWeb is using an older version of WebKit than what is available in Leopard.

    Thanks!

  2. Also, one issue I found, which you probably won’t notice if you’ve installed your own version of rubygems, but the rubygems package that is installed on Leopard doesn’t include gem_server (or gem server).
    I’ve filed this with Apple, and they seem to be aware of it.

  3. if I do a ‘gem list’, I only see the gems that are supplied, and not the ones I installed later. (they are present in the /Library… directory though. My gems are also not available to my projects.
    what might be the problem there?

  4. Thomas: Did you update rubygems? In any case, you want to make sure that GEM_HOME is set correctly. That’s where rubygems puts the ones you install “later”. GEM_PATH seems to be correct since it shows the ones that are supplied by the system (and are thus read-only.) See the instructions in this blog post for how to do that.

  5. I did, as you describe in your post. both environment variables are set (i’m using tcsh though)
    Ah, just noticed, that my gems got installed into a third directory “/Library/Ruby/Gems/gems” and not the “1.8” subdirectory…

    any idea why?

  6. It seems it always tries to install the gems in the /Library/Ruby/Gems directory, and ignore the “1.8” subdir. I do have the env variables set correctly though, and they also show up correctly with “gem environment”.
    I moved those directories outside the “1.8” subdir inside, and the gems now show up correctly with “gem list”.
    Unfortunately I can’t install or update any gems. I get this error:

    /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `gem_original_require’: no such file to load — sources (LoadError)
    from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `require’
    from /Library/Ruby/Site/1.8/rubygems/source_info_cache.rb:6
    from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `gem_original_require’
    from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `require’
    from /Library/Ruby/Site/1.8/rubygems/remote_installer.rb:12
    from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `gem_original_require’
    from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `require’
    from /Library/Ruby/Site/1.8/rubygems.rb:112:in `manage_gems’
    from /usr/bin/gem:10

  7. hmm, why does rubygems try to install the gems parallel to the 1.8 directory? the paths are correct and I checked the environment.
    any ideas? is there an other environment variable at work, or some config file that got mashed up, when I originally updated rubygems? (which is the obvious reason, as you point out in your article)

  8. Thomas: I ran into the same problem before. If you install any gems while it is in the bad updated state, it will install them into /Library/Ruby/Gems and you will have to delete them and reinstall them once you fix up the GEM_HOME environment variable above. Make sure you source your ~/.bash_profile to make the environment variable available.

  9. actually I know the problem now exactly.
    The problem is, that the sudo command doesn’t share the environment with the user space. adding the GEM_HOME and PATH variables to bash or tcsh in my case doesn’t solve the problem.
    I don’t know how to add environment variables to the root users environment. (i also added them to .MacosX/environment.plist, but that just makes them available to other applications outside the shell)

    I actually can install the gems fine just without using sudo, as the regular user has access to the gems directory, and everything works fine.

    hope someone can clarify this a bit. I also don’t know if its a problem installing the gems without sudo now, but it seems to work just fine

  10. Good catch. I noticed that I didn’t have to use sudo after updating rubygems and setting GEM_HOME and GEM_PATH. Thanks for pointing out that sudo doesn’t preserve those variables.
    Now I enjoy leaving out sudo and just doing “gem install …”

  11. I’m still having problems. Example:

    hume:~ mattleopard$ gem update fastthread
    Updating installed gems…
    Attempting remote update of fastthread
    Select which gem to install for your platform (universal-darwin9.0)
    1. fastthread 1.0.1 (ruby)
    2. fastthread 1.0 (ruby)
    3. fastthread 1.0 (mswin32)
    4. fastthread 0.6.4.1 (ruby)
    5. fastthread 0.6.4.1 (mswin32)
    6. Skip this gem
    7. Cancel installation
    > 1
    Building native extensions. This could take a while…
    ERROR: While executing gem … (Gem::Installer::ExtensionBuildError)
    ERROR: Failed to build gem native extension.

    ruby extconf.rb update fastthread
    can’t find header files for ruby.

    Gem files will remain installed in /Library/Ruby/Gems/1.8/gems/fastthread-1.0.1 for inspection.
    Results logged to /Library/Ruby/Gems/1.8/gems/fastthread-1.0.1/ext/fastthread/gem_make.out

  12. Following your instructions fixed a “command not found” problem I was having after installing and trying to run piston.

    One of the first things I did after getting Leopard was a gem system update and now I’ve got copies of gems EVERYWHERE lol. I’m afraid to delete anything now!

    Anyway, thank you so much!

  13. How long do you think Ruby will remain on 1.8? As soon as Ruby is updated to a new major version, you’ll have to change your environment variable settings.

    I would expect Apple will implement a system of symbolic links pointing to the latest version of Ruby. That’s how they manage Java. Then all you’d have to do is set GEM_PATH to /System/Library/Frameworks/Ruby.framework/Versions/Current and never have to change your environment variable again.

    Apple has implemented this partially in Leopard. Maybe because the system is incomplete, we’re having these problems.

  14. @Thomas and Luis:

    There’s a symbolic link ‘user-gems’ which points to /Library/Ruby/Gems. I would think this link is overriding the environment variable settings. (This link is located at /System/Library/Frameworks/Ruby.framework/Versions/Current/usr/lib/ruby.)

    As for setting up environment variables in the root account. You could open a root shell with…

    sudo su –

    This will open a root shell which inherits the environment variables in the root account’s .profile or .tcshrc file which you would maintain in the root account’s home, /var/root.

  15. I don’t think this is just an Apple issue. I updated my Gutsy Gibbon gem package and I had the same issue.

    I did not look into it any deeper. I just reinstalled my gem packages and I was back up and running…

    BTW: I had to reinstall the Rails gem too.

Comments are closed.