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. 
> 
FPC should decide whether and how to share modules between multiple interpreters
that don't have 100% compatibility with each other before the interpreters
start sharing their module packages.

-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/20130116/497aab29/attachment-0001.sig>