Hi,
Leopard, Mac OS X 10.5, will very soon be available to everyone!
Many of you have been wondering about the changes that will impact the
Ruby environment. We preventively compiled a list of all changes, and
you can now access it from here:
http://ruby.macosforge.org
http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard
As you can see we also just created a new Ruby project on MacOSForge,
with the aim of providing more information regarding the usage of Ruby
on the Mac in the future.
Enjoy!
Laurent
On Oct 25, 2007, at 1:42 PM, Laurent S. wrote:
with the aim of providing more information regarding the usage of Ruby
on the Mac in the future.
Thanks for all the work that you’ve put into this, Laurent. Looks
like a great resource, and I for one appreciate Apple’s support for
Ruby.
I didn’t notice Apple had integrated the DTrace stuff as is. The only
shame is that adding stuff like the gems I use I’ll have to do outside
of Macports.
Still - really good job tbh.
On Oct 25, 2007, at 12:42 PM, Laurent S. wrote:
The wiki page says that “The gem_server utility is not part of the
client distribution of Leopard. It is only provided in the server.”
This seems a very horrible omission – gem_server is used regularly
to view the RDoc documentation for installed gems. Is there another
mechanism in Leopard to view RDoc for installed gems? A nice Cocoa
app perhaps 
Blessings,
TwP
On Fri, Oct 26, 2007 at 06:49:03AM +0900, Tim P. wrote:
The wiki page says that “The gem_server utility is not part of the
client distribution of Leopard. It is only provided in the server.”
This seems a very horrible omission – gem_server is used regularly
to view the RDoc documentation for installed gems. Is there another
mechanism in Leopard to view RDoc for installed gems? A nice Cocoa
app perhaps
As a side note, the latest RubyGems code moves the gem_server
functionality
into the gem command, accessed via gem server. So in the future
providing
this only on the server version of OS X wouldn’t make sense as it will
just
be part of the gem command and likely, by that point, RubyGems will be
bundled with Ruby itself…
marcel
On 10/25/07, Laurent S. [email protected] wrote:
As you can see we also just created a new Ruby project on MacOSForge,
with the aim of providing more information regarding the usage of Ruby
on the Mac in the future.
Enjoy!
Laurent
Looks good, except I didn’t see anything about how to upgrade ruby or
ruby gems…will it be as easy as the doing ‘sudo port upgrade ruby’ ?
On 10/25/07, Marcel Molina Jr. [email protected] wrote:
On Fri, Oct 26, 2007 at 06:49:03AM +0900, Tim P. wrote:
On Oct 25, 2007, at 12:42 PM, Laurent S. wrote:
Leopard, Mac OS X 10.5, will very soon be available to everyone!
Many of you have been wondering about the changes that will impact the
As a side note, the latest RubyGems code moves the gem_server functionality
into the gem command, accessed via gem server. So in the future providing
this only on the server version of OS X wouldn’t make sense as it will just
be part of the gem command and likely, by that point, RubyGems will be
bundled with Ruby itself…
Apple’s decision to restrict gem_server to the server version of
Leopard seems out of tune, considering things like the fact that OSX
already includes Apache as part of the desktop version of the OS.
I find myself conflicted about whether to use the Apple packaging of
Ruby when I eventually upgrade to Leopard or continue to use either
the macport version or compile from sources. On Ubuntu, I’ve always
compiled from source so as to have better control over my development
environment.
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On Oct 25, 2007, at 9:42 PM, Rob S. wrote:
http://ruby.macosforge.org
Looks good, except I didn’t see anything about how to upgrade ruby or
ruby gems…will it be as easy as the doing ‘sudo port upgrade ruby’ ?
http://robsanheim.com
http://thinkrelevance.com
Uh, no.
Not if it isn’t installed via Mac Ports (formerly known as Darwin Ports)
But it is likely that the current (or a future) one-click installer
will be maintained for custom installs…
but with a better bundled Ruby, we might see even Apple making use of
its install. They already occasionally make use of Perl and Python
bundled with OS X.
On 10/26/07, Rob S. [email protected] wrote:
Looks good, except I didn’t see anything about how to upgrade ruby or
ruby gems…will it be as easy as the doing ‘sudo port upgrade ruby’ ?
Unfortunately no, sorry, but you should still be able to manually
build Ruby in /usr/local, exactly as in Tiger. Or use MacPorts.
Laurent
On 10/26/07, Marcel Molina Jr. [email protected] wrote:
be part of the gem command and likely, by that point, RubyGems will be
bundled with Ruby itself…
gem_server wasn’t packaged in the client because it was decided at the
beginning that serving gems over the network wasn’t intended to be
done by desktop users, but more server users. If you feel disappointed
I recommend you to file a bug at http://bugreporter.apple.com, the
more bugs we receive the more it will look important to the
management.
We understand that many people are using gem_server to read RDocs, and
will be worried by this decision, that’s why we put it in the article.
We however think that starting a web-server just to read RDocs is a
bit overkill, since you can point Safari to one of the sub-directories
of /usr/lib/ruby/gems/1.8/doc.
The fact that gem_server’s functionality is moving into the gem
command in the next gems release is a pretty good idea (like most of
the other changes also), and we are excited about that.
Laurent
On Oct 26, 2007, at 11:12 AM, Laurent S. wrote:
Unfortunately no, sorry, but you should still be able to manually
build Ruby in /usr/local, exactly as in Tiger. Or use MacPorts.
i would humbling suggest that mac not follow the path tread but
redhat and a billion other oses of scattering installs all over the
place and not using standard practices for upgrade - it’s a sad
statement that at noaa we do all of our serious package management
outside of rpms (building everything by hand) and i’ve been doing the
same on mac for the same reason: a system that leverages open source
without the ability to follow the rapidly moving pace of the
packages’ development has complete missed one of the main features of
open source and is, for me and my clients, utterly useless -
inability to keep up with head or, at least, do that via a package
manager renders open source to be effectively closed
respectfully,
a @ http://codeforpeople.com/
On 10/26/07, Giles B. [email protected] wrote:
illustrates exactly that problem, because it’s already happened - the
new gems is in pre-release already.
Hmmm, why not provide the XCode project files so that we can create
our own Ruby framework. I assume the framework in a user’s Library
folder would supersede the System folder. Just a thought.
TwP
On Oct 26, 2007, at 2:49 PM, Tim P. wrote:
had to last time anyway, because Ruby will probably change again
Arguably it should all be part of software management system.
Though MacPorts should not be the only option.
It is a bit short sighted in some regards, but we do have to
acknowledge that as an operating system/platform it needs to have a
stable & reliable official release to develop around, as well.
There are indeed both the bleeding edge people and the stable/
reliable/predictable people. Both camps have valid merits.
Personally, I was (unrealisticallly) hoping for Ruby 2.0 & Rails 2.0
all rolled up together in the new OS X…
On Oct 26, 11:33 am, “Giles B.” [email protected] wrote:
the Ruby schedule is
totally independent of the OS X schedule and co-ordinating the two in
any way at all is illogical wasted effort.
we’re going to have to manually update our Ruby installs just like we
had to last time anyway, because Ruby will probably change again
before OS X does. the “gem server” (not gem_server any more) example
illustrates exactly that problem, because it’s already happened - the
new gems is in pre-release already
In terms of a ruby developer’s workstation, I can agree with you. I’ve
been running the preview releases for a while now, and installing my
own build of Ruby in a different directory was one of the first things
I did.
However, there is a clear benefit to having some version of Ruby
installed by default as a system framework given that we can now
pretty easily use it to provide the guts of native Cocoa applications.
It’s nice to be able to write such an app for general distribution
without having to worry about whether your end-user has Ruby installed
correctly (or at all) with the objective C bridge enabled.
–
Regards,
John W.
The thing you’re all missing by installing your own build is the
DTrace functionality included in the build in OSX.
Also Ruby doesn’t change “that” much in 2 years. I don’t see what the
problem is if I am honest.
a system that leverages open source
without the ability to follow the rapidly moving pace of the
packages’ development has complete missed one of the main features of
open source and is, for me and my clients, utterly useless -
inability to keep up with head or, at least, do that via a package
manager renders open source to be effectively closed
I wouldn’t go as far as that, but it definitely does result in
crippled versions of Ruby. Laurent et al. @ Apple set up a custom
install so they could get the latest Ruby into the latest OS X. the
problem is, the whole idea of that is off. it’s fundamentally
flawed because you’re not really shipping software that goes on a
platform - you’re just shipping the platform. the Ruby schedule is
totally independent of the OS X schedule and co-ordinating the two in
any way at all is illogical wasted effort.
what you really need to do is say, some of our users are open source
power users who want the latest language. what you’ve set up in
attempt to give us that is guaranteed to not satisfy our needs
because it assumes that OS X is a product rather than a platform, and
Ruby is a feature rather than a language. packaging it up for us just
wastes our time, and causes dismay and confusion among newbies.
we’re going to have to manually update our Ruby installs just like we
had to last time anyway, because Ruby will probably change again
before OS X does. the “gem server” (not gem_server any more) example
illustrates exactly that problem, because it’s already happened - the
new gems is in pre-release already.
you need to make a fundamental distinction between features you
provide and communities you support.
–
Giles B.
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/
On Oct 26, 2007, at 2:33 PM, Giles B. wrote:
we’re going to have to manually update our Ruby installs just like we
had to last time anyway, because Ruby will probably change again
before OS X does. the “gem server” (not gem_server any more) example
illustrates exactly that problem, because it’s already happened - the
new gems is in pre-release already.
I really don’t follow this line of reasoning. Rubygems itself is
just a Ruby library and that Ruby library can be replaced/overridden.
If you look at the load paths that Apple set in leopard:
irb
puts $:
/Library/Ruby/Site/1.8
/Library/Ruby/Site/1.8/powerpc-darwin9.0
/Library/Ruby/Site/1.8/universal-darwin9.0
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
1.8/powerpc-darwin9.0
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
1.8/universal-darwin9.0
.
The site dir normally is parallel to the standard ruby lib dir
something like:
/usr/local/lib/ruby/1.8
/usr/local/lib/ruby/site_ruby/1.8
But Laurent moved that on OS X into /Library/Ruby/Site. So, if you
install a later rubygems in /Library/Ruby/Site/1.8 then it will
override the rubygems that is installed in the OS (and the ‘gem’
command will use the one you upgraded first)
Gems are the same way. If you gem install/update a gem it will go
in /Library/Ruby/Gems/1.8 and higher version gems will always be the
ones loaded.
What Apple did was provide a foundation that THEY can build upon (in
the OS) and we can update ourselves. I think that is an awesome
balance. They also built a bunch of native gems in that are a PITA
to build yourself by hand.
Of course if you need within your Mac to always run the latest SVN
build of Ruby just download that source and build it and install it
wherever you want.
Realize they could have totally screwed this up by reordering the
above load paths, but Laurent is a smart guy 
Best,
Rich
On 10/27/07, Lee P. [email protected] wrote:
The thing you’re all missing by installing your own build is the
DTrace functionality included in the build in OSX.
Also Ruby doesn’t change “that” much in 2 years. I don’t see what the
problem is if I am honest.
The problem is for people working with Ruby for paying clients
everyday. When a security update comes out in two months, and my
production sites all start using it immediately, Leopard’s version of
Ruby becomes useless to me. I want to run the version that my
clients are running in production, so I’ll end up using macports again
anyways (assuming the port is kept up to date), or just installing
from source.
It seems like Apple could’ve just preinstalled Ruby via macports,
giving us integrated goodness and the ability to upgrade for power
users. I realize macports as its flaws, but I’ve used it to bootstrap
3 or 4 machines over the past month with a full Ruby/Rails/mysql/etc
stack and it just works.
On Oct 27, 2007, at 11:03 AM, Richard K. wrote:
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
(in the OS) and we can update ourselves. I think that is an
Best,
Rich
boy you nailed that one on the head. They did it for them.
Truth is, anybody seriously doing development in Ruby outside of
something OS X 10.5-centric will probably need to create their own
install at some point.
If you’re doing RubyCocoa, it might be good to go with the stock
install, since it is easily and predictably deployable.
If you’re doing Rails or something to be deployed on a different
platform, you’ll be better with a custom setup.
It’s no big deal. We still have Hivelogic for reminders!
On Oct 27, 2007, at 3:21 AM, Lee P. wrote:
Also Ruby doesn’t change “that” much in 2 years. I don’t see what the
problem is if I am honest.
With a Ruby 1.9.1 release planned for Christmas using an all new
virtual machine and having an m17n implementation, this might not be
the best time to make such statements.
James Edward G. II