----- 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_g...
>> [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