Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation

[Toshio Kuratomi]

On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote:
> As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
> to pass through the community review by announcing them on devel-announce list.
> FESCo votes on new features no sooner than a week from the announcement.
> 
> = Features/JRuby 1.7 =
> https://fedoraproject.org/wiki/Features/JRuby_1.7
> 
> * Detailed description:
> Transition to JRuby 1.7 will consist of 3 basic steps:
> 
> - Updating packages
>  Most of the packages that JRuby depends on are in Fedora just because of JRuby, 
>  so they can be safely updated.
>  Some dependencies are shared with other packages, so they will have to be 
>  discussed with their owners (see #Scope). 
> 
> - Integration with Fedora
>  Normally, each Ruby implementations ships with its own copy of RubyGems 
>  library. This is wrong because a) it's bundling, b) there is no reason 
>  why multiple Ruby implementations wouldn't be able to share one RubyGems 
>  library. There used to be some differencies in JRuby's copy of RubyGems, 
>  but the JRuby upstream has been very cooperative and managed to get them 
>  all merged into upstream RubyGems.
>  The integration will require changing Fedora's operating_system.rb (place 
>  for distro-specific defaults for RubyGems). This change will result into 
>  all Gems with binary extensions having to be recompiled, as the binary 
>  extension placement will change. See [1] for current operating_system.rb 
>  look and its changes from F18.
>  What should "/usr/bin/ruby" point to? During standard Gem packaging process,
>  the executable files in Gems get shebangs according to the binary that they
>  are packaged with (Ruby => "/usr/bin/ruby"; JRuby => "/usr/bin/jruby"). 
>  Therefore executing a Ruby "binary" runs the interpreter that was used for 
>  building (or the hardcoded one, which is usually Ruby). Using alternatives 
>  for "/usr/bin/ruby" doesn't seem to be a very good option, because Ruby and
>  JRuby are not in fact full alternatives, as they for example cannot use same
>  extension Gems (but it still makes sense to allow executing same binaries 
>  with them). Also, alternatives are only switchable on admin level (we want
>  every developer with non-root privileges to be able to choose the 
>  interpreter). Therefore Ruby-SIG has come up with solution of having 
>  "/usr/bin/ruby" as a bash script (currently called rubypick) [2], that 
>  allows user to choose the interpreter as first argument on invocation 
>  (_mri_ or _jruby_), if such a parameter is present. Otherwise it falls 
>  back to a default. For example invoking "ruby_binary _jruby_ --foo=bar" 
>  in fact invokes "/usr/bin/jruby ruby_binary --foo=bar". This bash script 
>  will be in a separate package and both Ruby and JRuby will depend on it.
>  Ruby-SIG knows that this feature might be controversial and we wouldn't 
>  want it to stop us from bringing JRuby's power to Fedora (if met with a 
>  heavy resistance). So if anyone will suggest a more suitable solution, 
>  we'll go with it instead of this one. 
>     
> - Changes in packaging
>  None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of 
>  the box, but packaging of Gems with JRuby extensions is turning out to be 
>  very complicated, so the guidelines for it will be postponed to next release 
>  (as well as the actual packaging). Users will be still able to install Gems 
>  with JRuby extensions, both system-wide (into /usr/local/) and into their 
>  home directories. 
> 
> [1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb
> [2] https://github.com/bkabrda/rubypick 
>
As JRuby is setup to share pure ruby gems with ruby, I don't think this can
be approved (inlcuding the update to the jruby package to do this) until FPC
rules on whether it's okay for interpreters and languages which are not
completely compatible to share modules.  FPC will hopefully have quorum
tomorrow morning to meet.  If not, or if they have issues with the
guidelines, perhaps slavek and I can meet to try to figure out ways around
the issues.  I'll know more after the FPC meeting time tomorrow morning.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130122/77da2988/attachment.sig>