[ANN] Ruby Changes in Leopard

ruby-talk
1

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

2

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.

···

On Oct 25, 2007, at 1:42 PM, Laurent Sansonetti 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
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.

3

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 :wink:

Blessings,
TwP

···

On Oct 25, 2007, at 12:42 PM, Laurent Sansonetti wrote:

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

4

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' ?

- Rob

···

On 10/25/07, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

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

5

We received many valuable feedback during the past days, thank you
very much! We also received lots of pertinent questions, and since
most of them were asked many times, we decided to open a FAQ:

http://trac.macosforge.org/projects/ruby/wiki/FAQ

We will continue populating the FAQ while we receive more feedback.

Regards,
Laurent

···

On Oct 25, 2007 7:42 PM, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

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

6

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 25 Oct 2007, at 19:52, Lyle Johnson wrote:

On Oct 25, 2007, at 1:42 PM, Laurent Sansonetti 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
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.

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.

7

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 Fri, Oct 26, 2007 at 06:49:03AM +0900, Tim Pease wrote:

On Oct 25, 2007, at 12:42 PM, Laurent Sansonetti 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
>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

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 :wink:

--
Marcel Molina Jr. <marcel@vernix.org>

8

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 Oct 25, 2007, at 9:42 PM, Rob Sanheim wrote:

On 10/25/07, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

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

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' ?

- Rob

http://robsanheim.com
http://thinkrelevance.com

9

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, Rob Sanheim <rsanheim@gmail.com> 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' ?

10

We received many valuable feedback during the past days, thank you
very much! We also received lots of pertinent questions, and since
most of them were asked many times, we decided to open a FAQ:

http://trac.macosforge.org/projects/ruby/wiki/FAQ

Thank you for all of the great work, and the FAQ. However, there's one
question I have that I didn't see answered.

The "What's new" page states:

Ruby libraries or extensions that you install manually, will go in
/Library/Ruby/Site/1.8, which is empty after the installation, but
part of the default Ruby load path before others. You can therefore
install any Ruby library or extension without worrying about
incidentally modifying things in /System.

My question is, what about ruby *applications* that I install
manually? That is, a ruby package that contains a main executable
script, which currently goes into /usr/local/bin when I pass "--
prefix=/usr/local" into the "setup.rb config" command that I use
during installation? Where will the executable script go by default
under Leopard? Will it go into /usr/bin?

Right now, I only have a single such program installed and which I
rely on, which is misen (http://devel.korinkan.co.jp/misen/\). When I
upgrade to Leopard, I was thinking of removing my entire custom ruby
installation from /usr/local, and relying on the built in one. But
what will happen if I try to install misen?

···

On Oct 30, 10:10 am, "Laurent Sansonetti" <laurent.sansone...@gmail.com> wrote:

11

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.

By the way Marcel, are you working on something like this for RubyConf?

···

On 10/25/07, Marcel Molina Jr. <marcel@vernix.org> wrote:

On Fri, Oct 26, 2007 at 06:49:03AM +0900, Tim Pease wrote:
> On Oct 25, 2007, at 12:42 PM, Laurent Sansonetti 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..

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

12

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 10/26/07, Marcel Molina Jr. <marcel@vernix.org> wrote:

On Fri, Oct 26, 2007 at 06:49:03AM +0900, Tim Pease wrote:
> On Oct 25, 2007, at 12:42 PM, Laurent Sansonetti 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
> >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
>
> 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 :wink:

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..

13

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 Oct 26, 2007, at 11:12 AM, Laurent Sansonetti wrote:

Unfortunately no, sorry, but you should still be able to manually
build Ruby in /usr/local, exactly as in Tiger. Or use MacPorts.

--
share your knowledge. it's a way to achieve immortality.
h.h. the 14th dalai lama

14

In case other run into the same problems, I stuck together a few tips
to get gem_server back and working in Leopard.

http://fluctisonous.com/2007/11/8/where-has-my-gem_server-gone

···

On Oct 26, 5:12 pm, "Laurent Sansonetti" <laurent.sansone...@gmail.com> wrote:

On 10/26/07, Rob Sanheim <rsanh...@gmail.com> 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

15

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.

</rant>

···

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/

16

Instead of doing all of this, you can simply copy gem_server from the
RubyGems distribution, to /usr/bin.

Or create it yourself:

  #!/usr/bin/env ruby
  require 'rubygems/server'
  Gem::Server.run ARGV

Laurent

···

On Nov 9, 2007 2:18 AM, J2M <james2mccarthy@gmail.com> wrote:

In case other run into the same problems, I stuck together a few tips
to get gem_server back and working in Leopard.

http://fluctisonous.com/2007/11/8/where-has-my-gem_server-gone

On Oct 26, 5:12 pm, "Laurent Sansonetti" > <laurent.sansone...@gmail.com> wrote:

> On 10/26/07, Rob Sanheim <rsanh...@gmail.com> 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

17

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 10/26/07, Giles Bowkett <gilesb@gmail.com> wrote:

> 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*

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.

18

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.

<snip>

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.

···

On Oct 26, 11:33 am, "Giles Bowkett" <gil...@gmail.com> wrote:

--
Regards,

John Wilger

19

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 :slight_smile:

Best,

Rich

···

On Oct 26, 2007, at 2:33 PM, Giles Bowkett wrote:

20

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, 2007, at 2:49 PM, Tim Pease wrote:

On 10/26/07, Giles Bowkett <gilesb@gmail.com> wrote:

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*

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.

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