Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#15912 closed enhancement (fixed)

ruby port group: prepare for ruby 1.9

Reported by: febeling@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.7.0
Component: base Version: 1.7.0
Keywords: Cc: kimuraw (kimura wataru)
Port:

Description

Enhance the ruby.setup command so that it takes an additional optional argument implementation which determines the ruby-implementing port. This can be ruby and ruby19 for now. This value determines the ruby binary to use for installation, which in turn makes values from rbconfig.rb active for the undergoing installation.

This parameter willl also determine the port name prefix. So far it is always "rb-", it will be rb for 1.8 ruby and rb19 for ruby 1.9, following the example of python port prefices.

Attachments (2)

ruby-1.0.tcl (3.5 KB) - added by febeling@… 10 years ago.
test cases, put into subdir group/tests to run
add_parameter_implementation_to_ruby_group_setup.patch (3.7 KB) - added by febeling@… 10 years ago.
patch to change ruby port group as described; fix a regression with gem type rbports

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by febeling@…

Attachment: ruby-1.0.tcl added

test cases, put into subdir group/tests to run

comment:1 Changed 10 years ago by raimue (Rainer Müller)

Do we really need to split up the ports? It causes a lot of work for py-* and py25-* because we have no way to keep them in sync easily. So there are many python modules in the tree with different maintainers and different versions for py-* and py25-*.

I am not a ruby expert so I don't know if there is a need to keep ruby 1.8 and ruby 1.9 around at the same time.

comment:2 in reply to:  1 Changed 10 years ago by febeling@…

Cc: kimuraw@… added

Replying to raimue@macports.org:

Do we really need to split up the ports? It causes a lot of work for py-* and py25-* because we have no way to keep them in sync easily. So there are many python modules in the tree with different maintainers and different versions for py-* and py25-*.

As much as I'd like to avoid this complexity, I'm still convinced that we need it. Depending on variables collected during build phase of ruby itself, the standard installers choose the library paths to install files into. And these paths contain the ruby version as one element. For 1.8 we have these paths:

/opt/local/lib/ruby/site_ruby/1.8
/opt/local/lib/ruby/site_ruby/1.8/i686-darwin9.2.2
/opt/local/lib/ruby/site_ruby
/opt/local/lib/ruby/vendor_ruby/1.8
/opt/local/lib/ruby/vendor_ruby/1.8/i686-darwin9.2.2
/opt/local/lib/ruby/vendor_ruby
/opt/local/lib/ruby/1.8
/opt/local/lib/ruby/1.8/i686-darwin9.2.2

(Kimuraw changed this lately to exclude minor and teeny version numbers, though, for the arch-dependent directories.)

For 1.9 we get these:

/opt/local/lib/ruby/site_ruby/1.9.0
/opt/local/lib/ruby/site_ruby/1.9.0/i686-darwin9.3.0
/opt/local/lib/ruby/site_ruby
/opt/local/lib/ruby/vendor_ruby/1.9.0
/opt/local/lib/ruby/vendor_ruby/1.9.0/i686-darwin9.3.0
/opt/local/lib/ruby/vendor_ruby
/opt/local/lib/ruby/1.9.0
/opt/local/lib/ruby/1.9.0/i686-darwin9.3.0

I am not a ruby expert so I don't know if there is a need to keep ruby 1.8 and ruby 1.9 around at the same time.

I think we do need both installed in parallel, because 1.9 is tagged somewhat "experimental", still people will try to use it productively to profit from it's increased performance. There is some ambiguity about all this so they will probablt co-exist for quite a while.

The change between 1.8 and 1.9 is rather big, and it comprises syntax changes as well as internal changes, see [1]. Even if you were to install libs always using ruby 1.8, 1.9 would not pick them up, at least not unless you patch that ruthlessly into the standard ruby behaviour. That would mean either we make 1.9 pretend it was 1.8, or we make both drop the version component of the paths. Both would mean asking for trouble, imho.

I would love to hear how we can avoid this. I looked at linux distributions and only debian/testing has ruby1.9 so far (as of 3 weeks ago or so). And they go the same route and prepare packages for 1.8/1.9 in parallel.

I'll add kimuraw as the ruby 1.8 maintainer to CC. Maybe he has some more insight/an opinion on this issue.

[1] http://eigenclass.org/hiki/Changes+in+Ruby+1.9

Changed 10 years ago by febeling@…

patch to change ruby port group as described; fix a regression with gem type rbports

comment:3 Changed 10 years ago by febeling@…

I have a script which uninstalls, cleans, and installs all ruby port for regression testing. Pre- and port results are now exactyl the same.

comment:4 Changed 10 years ago by febeling@…

Resolution: fixed
Status: newclosed

Committed as r38683.

comment:5 Changed 10 years ago by blb@…

Milestone: MacPorts base enhancementsMacPorts 1.7.0
Note: See TracTickets for help on using tickets.