Friday, March 7, 2008

Rails Requires RubyGems >= 0.9.4 Error on Mac OS X

Updated 2008-10-08:
Please note that I forgot to mention in this post the fact that Ruby on Rails is installed by default with OS X Leopard. This blog is most helpful to those who had previously installed rails using MacPorts and now want to move to the Apple supported version that comes with OS X Leopard.

I was following along with the Apple Developer Connection article that shows how to update and use the version of Ruby on Rails that comes with Mac OS X Leopard. I followed through the article without a hitch. Successfully creating the Events Rails Site and viewing it at localhost:3000. The only change I made outside of the article's instructions was to add the script/generate and script/console commands to the same place as the article recommends the script/server. I figured keeping the original data model definition commands with the rails project would help if I wanted to make any changes to the data model later. I moved the data model definition commands to a shell script located in the top directory of the project. Which will make a nice portable design convention. I have seen that method mentioned in a blog post before.

While I was browsing around the running instance of the Events rails site I decided to do a full update of all the gem packages on my system by way of "gem update" without the "--system". Big mistake or so I thought when I tried to start my own rails project a day later. I couldn't even get the generate commands to run. The response from every script/ command was the same "Rails requires RubyGems >= 0.9.4. I googled around for the solution which always seemed to say remove the Leopard version and install the MacPorts version. Which I didn't want to do since I was trying to get rid of the duplicate MacPorts packages in the first place. In fact I had thought I had removed all the ruby packages from MacPorts. But on reinspection I found 4 versions of Ruby installed and one active a la "port search ruby and installed". First I did a "port uninstall ruby and inactive" to get rid of the old versions. Then I found a ruby gem I had somehow missed when I had done a "port uninstall rb-* and installed". After removing the lone gem I got rid of the installed and active version of Ruby via "port uninstall ruby". A quick verification of /opt/local/bin verfied that there was no longer a ruby or gem or update_rubygems command left.

Of course I left out the part where I removed all of the manually installed gems under /opt/local/lib/ruby/1.8/rubygems by "rm -fr / opt/local/lib/ruby/1.8/rubygems". Don't quote me on that path as I am writing this post on my iPhone and recalling it from memory. I only know the path because I also reinstalled rubygems manually before I figured out what the real problem was. I would probably have missed the real problem if I hadn't installed rubygems with "ruby setup.rb" after downloading it. The install commands showed RubyGems beings installed to /opt/local/... I had to remove that copy of RubyGems manually. Which wasn't so hard. All the install commands with the full paths of the installed files were still in my scrollback buffer.

I also didn't mention that I had uninstalled all my gem packages from the Leopard side of things. Including the original packages under /System. Luckily one of the articles I'd googled had the complete list. It was easy enough to do a "gem install rails sqlite-ruby capistrano mongrel libxml-ruby ruby-openid ruby-yadis rubynode RedCloth sources ferret acts_as_ferret fcgi termios cgi_multipart_eof_fix daemons dnssd gem_plugin hpricot needle actionwebservice activesupport". The full list of preinstalled gem packages is available here. I abbreviated my gem install command to only include what is necessary as installing rails pulls in some of the other packages in the list like activerecord and rake.
Everything worked like a charm after that. Now on to writing that SFA app. After that I'll have to get back to my holy war to remove redundant MacPorts packages. I think I was up to removing those two verions of Python 2.4 and 2.5. Seeing as how Leopard ships with 2.5 and 2.4 was a buggy beast at best when compared to the speed and bug fixes of version 2.5.

5 comments:

Tom Söderlund said...

Hi Daniel,

I saw your blog post that you have had some problems with multiple Ruby installations on Mac OS X. I think I have similar problems, leading to strange issues with RubyGems and Aptana RadRails.

What is best practice here? To:
1. Delete the OS X files (in /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby)
2. Delete the MacPorts files (in /opt/local/bin/ruby)
3. Keep both but change the path somehow?

Any input would be most helpful.

Thanks,

Tom.

DanyelLawson said...

Tom,

I recommend going with the OS X version of ruby and scapping the ports version. I say this because Apple seems to be upgrading and customizing the open source software installed with OS X. Rather than having to deal with incompatibilities and conflicts I recommend using the tools supplied by OS X to avoid future headaches.

Tom Söderlund said...

OK, thanks! So how would I treat new versions/updates of rails, gem etc? Should I update these and put the new files with the OSX ruby files?

Thanks!

Tom.

DanyelLawson said...

Yes. You can update rails and rubygems using the OS X installed version of ruby and rubygems. The OS X installed rubygems that come preinstalled are located under /System while and rubygems you install using sudo go under /Library. You can also install to the current users home directory.

The OS X installed version will let any manually installed rubygems override any of the OS X default rubygems installs. This default behavior allows for easy OS X upgrades that don't conflict with your manually installed rubygems.

Keep in mind that if you manually install older versions of a rubygem it will override the OS X installed version located under /System.

jak4 said...

I had a virtually the same problem, well the error message at least. But after checking and double checking that there were no legacy-ruby installations around it turned out the the boot.rb file within my application caused the error.

Generating a new boot.rb file with the updated rails version and replacing the old boot.rb file did the trick.

regards
jak4