FUDCon:Milan 2011 - Ruby SIG meeting

[Mo Morsi]

On 09/21/2011 07:46 AM, Vít Ondruch wrote:
> Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
>> Hello everybody,
>>
>> I'd like to bring to your attention that there was proposed by Ruby SIG
>> meeting as part of FUDCon Milan [1]. I would like to take this meeting
>> as change to discuss Ruby future in Fedora. Here are few point I'd like
>> to discuss:
>>
>> * Ruby 1.9.3 for F17. I have already pre-prepared feature page [2] for
>> this and I am working towards packaging Ruby 1.9.3. However, there are
>> several issues including
>>       - How to correctly name and version subpackages such as RubyGems,
>> RDoc, Rake, IRB
>>       - How to maintain updates of them late.
>>       - Directory structure.

Awesome! It's looking like Ruby 1.8 is quickly going the way of the 
dinosaur so I propose we just bite the bullet and update the main ruby 
package to 1.9. Then we can update all gems to the latest versions 
and/or the versions required to work with Ruby 1.9

If we still want to ship Ruby 1.8 I propose we simply fork off a 
compat-ruby-1.8 package and ship any additional compat packages for 
older versions of gems we want to ship.


>>
>> * Support of gems for MRI and JRuby.
>>       - Is it possible to share RubyGems?
>>       - Is it possible to share gems?

Its difficult since the gems themselves depend on the rubygems package 
which depends on MRI. Perhaps if we can break this dependency somehow 
this would be more feasible.

Just thought of a random idea, would the rubygems package be able to 
_not_ depend on a specific package, rather depend a 'ruby-interpreter' 
capability, which then would be provided by both the MRI and JRuby 
packages? Then MRI / JRuby could be swapped in / out and any gem that 
depends on a specific interpreter could have the MRI/JRuby dependency 
there instead having it in rubygems.

Granted this would make it more difficult to install both MRI and JRuby 
at the same time on the same system, though it may be feasible, just 
haven't thought this one through.


>> * Support of multiple versions of gems on single installation, e.g.
>> Rails 2 vs Rails 3.

We just need to ship a compat-rubygem-rails2 package and we should be 
good on this front.


>>
>> * Refresh of Ruby Packaging Guidelines
>>       - They do not always follow best practices
>>       - They will need to be updated because of Ruby 1.9.3

Agreed, be sure to keep us posted with any new ideas ya'll come up with. 
Going forward I think we should have a Ruby presence at all FUDCons. 
Probably won't be able to make Milan, but will try to make Blacksburg 
this January [1] (would be good to get away from the frigid Syracuse 
winter ;-) ).


>>
>> * gem2rpm future and possible extensions

Yes, yes, and more yes! :-)

We need to automate the gem -> rpm process, I am 100% confident that we 
can develop tooling to do so. Will alleviate alot of the hasstle w/ Ruby 
/ Fedora integration going forward.

> I have to add few more points immediately:
>
> * Rails 3.1 for F17

I still would like to hold off on this, we just updated to Rails 3 and I 
haven't seen much 3.1 adoption upstream yet. Maybe we can relook at this 
for F18 or F19.

>
> * Migration of RSpec to RSpec 2.x
>
>

This sounds reasonable as most new projects are using RSpec 2 nowadays. 
We most likely will still need to ship a compat-rspec1 package for those 
which haven't yet updated yet, though we can use this as an opportunity 
for the Fedora community to reach out and help those projects update.

Really appreciate all of this,

   -Mo