[ANN] Ruby Changes in Leopard
Laurent Sansonetti
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
Lyle Johnson
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.
Lee Packham
shame is that adding stuff like the gems I use I'll have to do outside
of Macports.
Still - really good job tbh.
Tim Pease
> 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
>
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
Marcel Molina Jr.
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
--
Marcel Molina Jr. <mar...@vernix.org>
Rob Sanheim
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
John Joyce
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.
Rick DeNatale
> 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..
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?
http://www.boingboing.net/2007/10/24/howto-make-a-killer.html
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Laurent Sansonetti
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
Laurent Sansonetti
> 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
ara.t.howard
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.
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/
--
share your knowledge. it's a way to achieve immortality.
h.h. the 14th dalai lama
Giles Bowkett
> *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/
Tim Pease
> > 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*
>
> 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
John Joyce
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...
John Wilger
> 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 Wilger
Lee Packham
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.
Rob Sanheim
> 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.
- Rob
John Joyce
On Oct 27, 2007, at 11:03 AM, Richard Kilmer wrote:
> On Oct 26, 2007, at 2:33 PM, Giles Bowkett 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
>
>
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!
James Edward Gray II
> 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 Gray II
Bil Kleb
>
> On Oct 27, 2007, at 11:03 AM, Richard Kilmer wrote:
>>
>> Realize they could have totally screwed this up by reordering the
>> above load paths, but Laurent is a smart guy :-)
+1
(Haven't seen Rich's original show up in comp.lang.ruby yet.)
Later,
--
Bil Kleb
http://nato-rto-latex.googlecode.com
Brian Adkins
> John Joyce wrote:
>
> > On Oct 27, 2007, at 11:03 AM, Richard Kilmer wrote:
>
> >> Realize they could have totally screwed this up by reordering the
> >> above load paths, but Laurent is a smart guy :-)
>
> +1
>
> (Haven't seen Rich's original show up in comp.lang.ruby yet.)
Me neither. Possibly an HTML post eaten by the gateway?
James Edward Gray II
Yes:
Content-Type: multipart/alternative; boundary=Apple-Mail-18-445454026
James Edward Gray II
David A. Black
I received it; it's ruby-talk: 276132.
David
--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
* Advancing With Rails, Edison, NJ, November 6-9
* Advancing With Rails, Berlin, Germany, November 19-22
* Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!
Pat Maddox
just planning on using macports cause it works so well.
Pat
Ben Mabey
I am wondering the same thing.. I currently compile from source but
would gladly switch to the built-in install if it is going to be kept up
to date. Is Apple going to be maintaining it so it stays current with
the latest version of ruby?
-Ben
James Edward Gray II
> Are there any compelling reasons to use the built-in install? I was
> just planning on using macports cause it works so well.
I think the built-in install will be great for deploying RubyCocoa
applications. You can count on it being there on other machines for
that purpose.
James Edward Gray II
James Edward Gray II
> Is Apple going to be maintaining it so it stays current with the
> latest version of ruby?
Yes, I'm very curious about this point as well. It'll be terrific if
they can bump it to 1.8.6p110 in an early bug fix patch. That's what
I'm hoping we gain out of this framework setup.
James Edward Gray II
James Edward Gray II
> Hi --
>
> On Sun, 28 Oct 2007, James Edward Gray II wrote:
>
>> On Oct 27, 2007, at 2:15 PM, Brian Adkins wrote:
>>
>>> On Oct 27, 2:21 pm, Bil Kleb <Bil.K...@NASA.gov> wrote:
>>>> John Joyce wrote:
>>>>> On Oct 27, 2007, at 11:03 AM, Richard Kilmer wrote:
>>>>>> Realize they could have totally screwed this up by reordering the
>>>>>> above load paths, but Laurent is a smart guy :-)
>>>> +1
>>>> (Haven't seen Rich's original show up in comp.lang.ruby yet.)
>>> Me neither. Possibly an HTML post eaten by the gateway?
>>
>> Yes:
>>
>> Content-Type: multipart/alternative; boundary=Apple-
>> Mail-18-445454026
>
> I received it; it's ruby-talk: 276132.
That's because it originated on the mailing list side. The gateway
then submitted it to our Usenet host and they declined it, so it
never hit comp.lang.ruby.
James Edward Gray II
Bill Kelly
From: "James Edward Gray II" <ja...@grayproductions.net>
>
>>>> Me neither. Possibly an HTML post eaten by the gateway?
>>>
>>> Yes:
>>>
>>> Content-Type: multipart/alternative; boundary=Apple-
>>> Mail-18-445454026
>>
>> I received it; it's ruby-talk: 276132.
>
> That's because it originated on the mailing list side. The gateway
> then submitted it to our Usenet host and they declined it, so it
> never hit comp.lang.ruby.
I'm sure this has been asked before, so apologies for what is
almost surely a repeat question, but ... :)
Would it be reasonable to just convert all messages to text-only
before submitting them to the Usenet host?
Another mailing list I'm on works that way, and it seems pretty
reasonable. If it modifies a message, it just appends a note,
like "non-text attachments stripped" or such.
Essentially, I'm wondering if the situation is,
- yes we could convert messages if someone volunteers code to do so
- no we shouldn't convert messages because of (some issue)
Thanks,
Bill
Laurent Sansonetti
We will provide updates, if the bugs they fix are important enough.
Security issues will also be fixed the soonest possible.
The version in Leopard is 1.8.6 p 36 + the security fixes that were
included in p110. p110 was unfortunately released a bit too late for
us.
Laurent
Laurent Sansonetti
The built-in version also provides DTrace support.
Laurent
John Tsombakos
The question I haven't seen asked (or answered) is how would I switch
from my /usr/local version of Ruby & Rails (and gems) to the Leopard
stock versions? I can't just pluck /usr/local/bin out of my PATH,
because there are other things installed there (ImageMagick, Subversion
[well, that's now system installed though], etc.) ?
Do I just delete/rename the applications? (ruby, irb, rake, svn*, etc)
--
Posted via http://www.ruby-forum.com/.
Michael Steinfeld
you can append /usr/local to the end of your PATH instead. if /usr/bin
is before /usr/local/bin in your PATH ENV then /usr/bin/whatever will
be found/used first.
I'd consider cleaning up your source_cache as well, and removing ~/.ruby_inline.
Also there is an issue with the compiler flags set using RubyInline
that you will want to fix.
I wrote a sed script to do it. Very helpful if you need to fix it on
multiple machines.
sudo sed -i -e "387,1s/flags\ =\ @flags.join(\'\ \')/&\ \+\ \'\
-lruby\'/" /usr/lib/ruby/user-gems/1.8/gems/RubyInline-3.6.4/lib/inline.rb
> --
> Posted via http://www.ruby-forum.com/.
>
>
--
Michael Steinfeld
Linux Admin/Developer
AIM: mikesteinfeld
GTALK: mikei...@gmail.com
John Tsombakos
> On 10/28/07, John Tsombakos <joh...@charter.net> wrote:
>> [well, that's now system installed though], etc.) ?
>>
>> Do I just delete/rename the applications? (ruby, irb, rake, svn*, etc)
>
> you can append /usr/local to the end of your PATH instead. if /usr/bin
> is before /usr/local/bin in your PATH ENV then /usr/bin/whatever will
> be found/used first.
>
> I'd consider cleaning up your source_cache as well, and removing
> ~/.ruby_inline.
> Also there is an issue with the compiler flags set using RubyInline
> that you will want to fix.
>
> I wrote a sed script to do it. Very helpful if you need to fix it on
> multiple machines.
>
> sudo sed -i -e "387,1s/flags\ =\ @flags.join(\'\ \')/&\ \+\ \'\
> -lruby\'/"
> /usr/lib/ruby/user-gems/1.8/gems/RubyInline-3.6.4/lib/inline.rb
Oh yeah! Didn't even think of that!
I don't seem to have a ~/.ruby_inline file (I installed using the
Hivelogic directions, from source), so not sure if I need to do that.
My source_cache is in the (now unused) /usr/local path, do I need to
worry about it?
Thanks!
Matt Mower
> We will provide updates, if the bugs they fix are important enough.
> Security issues will also be fixed the soonest possible.
>
When you say 'provide updates' can I just check that you do mean via
the Apple Software Update system?
Regards,
Matt.
--
Matt Mower :: http://matt.blogs.it/
John Tsombakos
> Michael Steinfeld wrote:
>> On 10/28/07, John Tsombakos <joh...@charter.net> wrote:
>>> [well, that's now system installed though], etc.) ?
>>>
>>> Do I just delete/rename the applications? (ruby, irb, rake, svn*, etc)
>>
>> you can append /usr/local to the end of your PATH instead. if /usr/bin
>> is before /usr/local/bin in your PATH ENV then /usr/bin/whatever will
>> be found/used first.
>>
..
> Oh yeah! Didn't even think of that!
>
> I don't seem to have a ~/.ruby_inline file (I installed using the
> Hivelogic directions, from source), so not sure if I need to do that.
>
> My source_cache is in the (now unused) /usr/local path, do I need to
> worry about it?
>
> Thanks!
Hmm.. I made that change, then tried to update gems (sudo gem update).
It seemed to be going well, until it hit this and died:
Installing ri documentation for activerecord-1.15.5...
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rdoc/rdoc.rb:101:in
`error': (RDoc::RDocError)
Directory /Library/Ruby/Gems/1.8/doc/activerecord-1.15.5/ri already
exists, but it looks like it
isn't an RDoc directory. Because RDoc doesn't want to risk
destroying any of your existing files, you'll need to
specify a different output directory name (using the
--op <dir> option).
James Edward Gray II
>
> From: "James Edward Gray II" <ja...@grayproductions.net>
>>
>>>>> Me neither. Possibly an HTML post eaten by the gateway?
>>>>
>>>> Yes:
>>>>
>>>> Content-Type: multipart/alternative; boundary=Apple-
>>>> Mail-18-445454026
>>>
>>> I received it; it's ruby-talk: 276132.
>> That's because it originated on the mailing list side. The
>> gateway then submitted it to our Usenet host and they declined
>> it, so it never hit comp.lang.ruby.
>
> I'm sure this has been asked before, so apologies for what is
> almost surely a repeat question, but ... :)
It's been asked, yes. We went over it again recently. See the
thread "Is there a standard pattern for threaded access to a file?"
which we sort-of hijacked for a gateway discussion.
> Would it be reasonable to just convert all messages to text-only
> before submitting them to the Usenet host?
Mostly, yes.
> Essentially, I'm wondering if the situation is,
>
> - yes we could convert messages if someone volunteers code to do so
This is pretty much it. I made the gateway code public some time ago
to support people hacking on it:
http://blog.grayproductions.net/categories/the_gateway
No one has stepped up yet. ;)
To be fair, I think some are waiting on the TMail-based rewrite I've
promised in the past. I've worked on it a bit, but just haven't
finished it yet. I'll spend some time on it today and see how close
I can get it…
James Edward Gray II
mortee
> The question I haven't seen asked (or answered) is how would I switch
> from my /usr/local version of Ruby & Rails (and gems) to the Leopard
> stock versions? I can't just pluck /usr/local/bin out of my PATH,
> because there are other things installed there (ImageMagick, Subversion
> [well, that's now system installed though], etc.) ?
>
> Do I just delete/rename the applications? (ruby, irb, rake, svn*, etc)
If you want to keep using your locally installed commands from
/usr/local/*, but switch back and forth between you custom version of
ruby and the system-provided one, then I'd recommend installing it under
a custom prefix (i.e. not /usr/local), and add/remove that path from
your PATH. At least that's what I would try to do - or play around with
symlinks. However, the PATH method can be switched at will on a
per-process basis, while using symlinks would affect the whole system at
once.
mortee
Laurent Sansonetti
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.s...@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
Karl von Laudermann
<laurent.sansone...@gmail.com> wrote:
> 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?
J2M
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
Laurent Sansonetti
RubyGems distribution, to /usr/bin.
Or create it yourself:
#!/usr/bin/env ruby
require 'rubygems/server'
Gem::Server.run ARGV
Laurent