JRuby masterplan for F19 - RFC

Mon Dec 3 07:54:08 UTC 2012

----- Original Message -----
> Dne 29.11.2012 09:43, Bohuslav Kabrda napsal(a):
> > Hi all,
> > as F19 is slowly approaching, I thought it'd be great to finalize
> > the stuff about JRuby/Ruby integration with Fedora. Here are the
> > changes and additions around JRuby, that I suggest:
> > * Global changes
> > - As already mentioned in [1], change the default
> > operating_system.rb, the current version is at [2]. The question
> > here is, whether to use versioned directories for extensions. In
> > my opinion we should do that, as users installing Gems under
> > /usr/local may want to install them for different version of JRuby
> > (Rubinius in the future). This change will cost us nothing and
> > will make sure that we can utilize this in the future.
> 
> We do not support more version of MRI nor JRuby nor we support
> anything
> else. The only exception would be if the interpreter support
> compatibility modes for different Ruby versions => I am against
> versioning in /usr/local unless explicitly needed.
> 

I meant the interpreters that support multiple compatible modes. So e.g. Rubinius users may want to install extensions under /usr/local for both ruby-1.8 and ruby-1.9 compat modes (once we have Rubinius). It is true, that for now this shouldn't be needed (as Charles has mentioned, JRuby extensions should work with both compat modes). I do not consider this to be a "must have" feature, so if you'll shout at me for a long enough time, I'll just give it up ;)

> > - Add additional macros to macros.rubygems, see [3] (if the macros
> > names seem confusing, see the section about packaging gems for
> > JRuby below).
> 
> The jruby/java suffixes are confusing. We should go only with one of
> them. I am inclined to -jruby (not sure why -java was chosen by
> RubyGems
> or as a platform)
> 

Yep, I agree that they may seem confusing. We may use "_jruby" (I'm assuming that you're talking about the macro names, not the actual directories/gemspecs/etc), but we have to find a good way of distinguishing between the extdir that contains "-java" suffix and extdir that doesn't contain it (for JRuby-only gems).
So how about
1) All the JRuby macros have "_jruby" suffix.
2) The ext dir for JRuby gems that don't contain "-java" in their name, the macro would be called sth. like %{gem_extdir_jruby_pure}.

> > - Two connected problems: 1) RPM generates auto provides from
> > shebangs, e.g. #!/usr/bin/ruby will automatically require ruby
> > package; 2) How to run programs with #!/usr/bin/ruby shebangs
> > under JRuby?
> > -- We've discussed this situation with Vit and we came up with an
> > interesting proposal for solution. There will be a package
> > (probably with just one file) /usr/bin/ruby. This will be a bash
> > script, that will take all given parameters and pass them to the
> > proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There
> > will be a default choice (MRI, I guess) and the switching will be
> > done by passing _jruby_ (possibly also containing version) or
> > _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not
> > found, the script will automatically try /usr/bin/jruby and if
> > that is not present either, it will print out that user needs to
> > install a Ruby runtime.
> 
> Please note that RubyGems are using similar approach already. E.g.
> you
> can run `rake _0.8.7_` to execute your rake task using explicitly
> defined version of Rake. So we would just extend this idea a bit
> further.
> 
> > -- This way, the automatically generated requires will point to the
> > package containing /usr/bin/ruby and not the actual ruby package,
> > therefore leaving it up to user which Ruby runtime he wants to
> > install.
> > -- Also, every executable file with this shebang can be run with
> > _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_", the
> > same for gem, irb and anything that has the proper shebang.
> 
> I would be interested if anybody know about any possible
> showstoppers.
> 
> >
> > * Changes to packaging
> > - Platform independent packages mustn't R: ruby, unless there is a
> > specific reason to do so.
> > - Packages with MRI binary extensions will have to R: and BR: ruby
> > explictly, not just ruby(abi), as that will also be provided by
> > JRuby.
> > - Packages meant only for JRuby will have to R: and BR: jruby
> > explictly (same reason). These will use the %gem_extdir_jruby
> > macro.
> > - Packages with extensions for both Ruby and JRuby (let's consider
> > rubygem-json, example of converted specfile is at [4]):
> > -- MRI extension will probably stay in the core package
> > (rubygem-json).
> > -- There will be a subpackage with -java suffix (because the naming
> > scheme on rubygems.org gives e.g. json-1.7.5-java). The subpackage
> > will contain it's own .gemspec and because all the directory/file
> > names contain the "-java" string, it will use the %gem_*_java
> > macros.
> > -- The -java subpackage will contain the JRuby extension under
> > %gem_extdir_java and it's platform independent part will be a
> > symlink to platform independent part of its MRI counterpart (e.g.
> > /usr/share/gems/gems/json-1.7.5-java ->
> > /usr/share/gems/gems/json-1.7.5).
> > -- The disadvantage of this approach is, that the core package
> > (rubygem-json) will be a dependency of rubygem-json-java,
> > therefore forcing MRI to be installed.
> >
> > or
> >
> > -- The rubygem-json-java package could be independent of
> > rubygem-json (e.g. everything same as above, except it will
> > actually contain the platform independent part). This would in
> > fact not require MRI ruby to be installed, but I'm not sure of the
> > consequences of this.
> > -- A big question is, how to handle provides (applies to both
> > cases). RPM cannot say "I'm fine with rubygem-json or
> > rubygem-json-java", so the -json package will probably have to
> > Provides: rubygem(json-java) and users will have to install these
> > manually, if they want to use JRuby.
> 
> Taking rubygem-json as an example, I'd love to see:
> 
> rubygem-json - contains platform independent code
> rubygem-json-mri - subpackage containing MRI binary extension
> rubygem-json-jruby - subpackage containing JRuby extension
> 
> Unfortunately, there is probably no way how to install proper
> subpackages, unless we would go with comps [1] for example. But I
> opened
> ticket on RPM [2] requesting support for this.
> 

Yep, that would be exactly what we need and we should really push for this. But I don't see this solution coming for F19, so we will have to make a temporary decision for the time being. Thinking of the two above alternatives further, I would prefer the first one, because the Requires: rubygem(json) will pull rubygem-json in anyway, so the second solution doesn't in fact bring benefits in terms of RPM dependencies.

> Vít
> 
> 
> [1]
> http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups
> [2] http://rpm.org/ticket/857

Thanks for your thoughts, Vit. I hope the others will comment as well :)

-- 
Regards,
Bohuslav "Slavek" Kabrda.