Frequently Asked Questions
Leopard-only Questions
How will the upgrade process for Ruby and Rails components work now? What do we need to keep in mind?
All the components that are delivered as gems can be easily upgraded using gem update.
Keep in mind that Leopard comes with 2 gems repositories, one in /System and one in /Library. Pre-installed gems will stay in /System, new versions will go in /Library. The versions in /Library will take precedence over those in /System, as usual.
There are 2 components that are not delivered as gems: the Ruby interpreter and the RubyCocoa bridge, which are considered part of the core of the system. These cannot be upgraded as easily.
Will we have to wait for apple to provide official software updates in order to update our Ruby interpreter base installation now (due to all of the patches and changes to support integration with OS X) instead of a simple download and update from ruby-lang.com?
It is preferable to leave the pre-installed Ruby interpreter untouched, as well as RubyCocoa. Apple will periodically provide software updates in order to address critical bugs or security issues.
If you want to use the bleeding edge, nothing prevents you to install your own version of Ruby or RubyCocoa separately, which is the approach is used by both Fink and MacPorts. Just be sure to set your $PATH variable appropriately, and you should be fine.
Will you upgrade the pre-installed Ruby (1.8) to 1.9?
Replacing Ruby 1.8 with 1.9 is not an option because it would break compatibility with existing code (scripts, and also RubyCocoa apps). We are very concerned about preserving compatibility.
If 1.9 was to be introduced, there is a big chance that we would keep 1.8 as well, inside the same framework, using the versioning capability.
Can we freely update ANY RubyGems (including the rubygems gem itself which now has a newer major update in beta) without blowing away Apple customizations?
Yes.
Can we freely update Rails to Rails 2.0 with a simple 'sudo gem install rails' without breaking things?
Yes.
I saw a number of issues you were trying to address with the mysql gem (a traditionally ornery gem) install in 10.5. Should we expect to have to change how we install and build gems that include components that need to be natively compiled?
Normally no. Installing the mysql gem on Leopard is problematic because MySQL.com doesn't provide universal binaries. Hopefully, most of the native libraries for Mac OS X are now provided as universal, since we started the PowerPC to Intel transition, and this kind of problem should not be expected very often.
Maybe you can speak now to how (and if) the Rails team was involved in the changes made during the 10.5 development process?
We collaborated with the Rails team in order to provide a very good Rails environment by default. They gave us a significant amount of feedback.
What's getting posted back in terms of source code for the open source community?
We are contributing all the changes we made to the upstream projects.
Most of the RubyCocoa bridge was re-written by Apple, including BridgeSupport, a new project that delivers metadata files for Objective-C bridges.
Why is gem_server not available, except in OS X server?
There was a conscious decision to reduce the number of services on the client that opened network ports (to simplify our security auditing) and it was felt that gem_server didn't provide enough unique value -- since you can get a similar effect by pointing Safari at the rdoc.
How can we get gem_server back?
Copying the gem_server script from the RubyGems distribution in /usr/bin would do the trick. Upgrading the RubyGems gem would also re-install the file.
Since 0.9.5, RubyGems have the gem_server functionality moved as part of the gem command.