JRuby masterplan for F19 - RFC

Tue Dec 4 14:54:35 UTC 2012

----- Original Message -----
> >>> - 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.
> 
> Ya this is very interesting. My only concern that somehow we'd break
> upstream tools and such, but I can't think of any specific ways so
> maybe
> I'm just being paranoid.
> 
> Of course the script would need to pass all additional command line
> flags to the interpreter and as you mentioned, if the first parameter
> is
> not detected to be 'mri' or 'jruby' we should have a default
> 
> Doesn't matter to me which one is the default, would people be
> interested to trying jruby as the default of Fedora 19? Or perhaps we
> should push that change off till the next Fedora release when all
> this
> will have stabilized a bit.
> 

I have just pushed all of this stuff into my testing repo [1] (the /usr/bin/ruby stub, modified MRI Ruby, etc.), so you can test that now. For me, it seems to work. I call the stub "multiruby" (actually Vit's idea :) ) and its upstream is at [2] (no fancy git tags and stuff, I just made it work for now...). By default, the stub uses MRI.
It seems to work ok, I have also tried benchmarking the execution time and the stub is 1 second slower in 1000 executions. That means 133 vs. 132 secs - that's 0.7 % slower, I think we can live with that :)
Please note that when working with my testing repo, you should only install to mock chroot, otherwise it can do bad things to your current Ruby installation. Also, the json gem may seem broken (cannot load extensions), but that is because F 19 places extensions in different directory and its version is newer than version in my repo. So if you want to workaround that, either install rubygem-json_pure into the chroot or "gem install json" in the chroot (this will place the extensions according to new layout).

> >>> * 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.
> 
> Ya also +1 to the first, seems like more naturally aligned w/ the
> current setup and tooling.
> 
> Also dislike the dependency on MRI for the jruby stuff, would be
> awesome
> to be able to get that feature into RPM.
> 

Yes, I'm also +1 for the first one, I was just presenting possibilities. Vit's proposed solution would be the best one, but it's currently not doable. I'm afraid that we won't get rid of installing MRI with JRuby for now, but I guess it's better than nothing :)

> 
> >> 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 :)
> >
> 
> Thanks to both of you for all of this, exciting times for Ruby on
> Fedora :-)
> 
>   -Mo

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] http://bkabrda.fedorapeople.org/jruby/jruby.repo
[2] https://github.com/bkabrda/multiruby