ruby_select and rvm

Joseph Holsten joseph at josephholsten.com
Wed May 19 11:54:48 PDT 2010


On May 19, 2010, at 11:37 AM, David Baumgold wrote:

> On Wed, May 19, 2010 at 2:24 PM, Joseph Holsten
> <joseph at josephholsten.com> wrote:
>> David Baumgold wrote:
>> 
>>> As far as I can tell, MacPorts has very poor support for Ruby 1.9. I'm
>>> going to be taking a class that requires using Ruby 1.9, so I have a
>>> big incentive to fix this. :) I know that MacPorts Python has the
>>> python_select port -- is there an equivalent ruby_select port? (I
>>> haven't found one, but I want to be sure.) I also recently discovered
>>> a project called rvm (http://rvm.beginrescueend.com/) which is
>>> designed for exactly this purpose. Can a more experienced MacPorts
>>> developer tell me what would be required to package rvm so that it
>>> works with MacPorts, and give me some tips for how to go about doing
>>> so?
>> 
>> Typical gem installation is done by
>> 
>> % gem install rvm
>> 
>> Gem portfiles are amazingly simple to create, see http://trac.macports.org/browser/trunk/dports/ruby/rb-actionmailer/Portfile for a good example.
> 
> Yeah, I've actually created a few Gem portfiles, myself. However, the
> Ruby PortGroup seems to assume that you are installing for Ruby 1.8,
> and I'm going to need some of the Gems for Ruby 1.9 -- in particular,
> Gems like Rake and RubyGems, which at the moment are only available
> for Ruby 1.8, as far as I can tell. In fact, the only Ruby Gem
> available for Ruby 1.9 at the moment is the rb19-mysql port. Or is
> there a way to tell Macports to install a Gem written for 1.8 into a
> Ruby 1.9 enviornment?

If you intend to use rvm, you should not be installing gems to those rubies system wide. RVM creates ruby installations in isolated environments, the only way to install gems into those environments is to RUN GEM AS A NON SUPER USER.  Please don't mind the screamy caps. If macports were to install rubygems for an rvm installation, that would be using a system wide package management tool to manage isolated, usually user-local, ruby environments. Macports does not have the ability to do that today. I don't think it's worth the time to add that functionality, since regular users shouldn't be using rvm. And I doubt that those features could be added without awkward changes to the way macports works.

>> I should mention that I could not make ruby 1.9 work through rvm, but my macports install runs perfectly. Strange that your setup would be opposite.
> 
> Oh, that's not what I meant. I can install and run ruby 1.9 perfectly
> fine. The issue is that the default Macports ruby is still Ruby 1.8:
> when I run "irb" it loads up 1.8, and I have to run "irb1.9" to load
> up 1.9. Macports can install multiple versions of Python
> simultaneously, and which version is called when you run "python" at
> the terminal is controlled by the python_select port. I'm saying that
> it would be really nice to have a similar "ruby_select" port, so that
> I could decide that I want Ruby 1.9 to be the default Ruby
> installation on my system, and just type "irb" to get a Ruby 1.9
> prompt. I figured that rvm would be a good way to start doing this,
> since it already contains infrastructure for setting system default
> interpreters like this. Does that make sense?

It does. In fact, I have macruby_select installed on my machine, though it's only for selecting between versions of macruby, not MRI. It would be a nice thing to have for macports ruby, I'll admit.

Perhaps it's possible to repurpose macruby_select? Frankly, I don't use MRI 1.9 at all, I'm so satisfied with macruby. I encourage you to install macruby for a bit to 	try it. If it's macruby_select seems to meet your needs, I'd be happy to help make it work with the macports rubies.
--
http://josephholsten.com


More information about the macports-dev mailing list