JRuby masterplan for F19 - RFC

[Bohuslav Kabrda]

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.
- Add additional macros to macros.rubygems, see [3] (if the macros names seem confusing,
see the section about packaging gems for JRuby below).
- 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.
-- 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.

* 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.

* Others:
- There is also a general problem with Provides/Requires of the interpreters themselves. I
think that JRuby should provide both ruby(abi) = 1.9.1 and ruby(abi) = 1.8. I'm
however not sure whether to provide e.g. rubygem(io-console), which is required by
rubygems package. The problem with this provide is this:
1) user installs JRuby (that provides rubygem(io-console)) and rubygems.
2) user installs MRI, rubygem-io-console doesn't get installed, as the dependency is
already satisfied.
3) "gem" command (specifically its part that depends on io-console) run under
MRI fails.
As I see it, we probably won't get rid of having MRI ruby installed with JRuby, at
least not for the near future (but at least the auto-requires of /usr/bin/ruby can be
handled, which is a step in the right direction).

I hope I made my points clear, please share your thoughts/comments/critisism.
BTW, I'll be updating my testing repo with JRuby as soon as JRuby 1.7.1 are out. When
we agree on how the stuff mentioned above should work and have it approved by FESCo/FPC,
I'll start pushing JRuby into F19, but that seems to be far away for now...

Thumbs up if you read the whole mail :)
Slavek.

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-November/001142.html
[2] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_syst...
[3] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/rubygems.spec#...
[4] https://github.com/bkabrda/jruby.spec/blob/master/rubygem-json/rubygem-js...

[Vít Ondruch]

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.

>  - 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)

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

Vít


[1] 
http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_g...
[2] http://rpm.org/ticket/857

[Bohuslav Kabrda]

----- 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_g...
>  [2] http://rpm.org/ticket/857 
Thanks for your thoughts, Vit. I hope the others will comment as well :)

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[Mo Morsi]

On 12/03/2012 02:54 AM, Bohuslav Kabrda wrote:
>  ----- 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 ;) 
Ya you both have good points. Feel Bohuslav's proposal would cover more
edge cases but Vit's makes a good argument for simplicity. Suppose I'm
leaning more towards being able to handle the multiple compatibility
modes (but then again I'm not the one implementing it!)


> >> - 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}. 
+1 to -jruby over -java

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


> >> * 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.


> > 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

[Bohuslav Kabrda]

----- 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

[Vít Ondruch]

Dne 4.12.2012 15:54, Bohuslav Kabrda napsal(a):
>  I call the stub "multiruby" (actually Vit's idea :) )
Well, if you have better idea how to name it, please speak out now :)

Considering that this method is similar to Alternatives [1] and 
Environment modules [2], may be we should find some better name for this 
general approach.

Vit



[1] http://fedoraproject.org/wiki/Packaging:Alternatives
[2] http://fedoraproject.org/wiki/Packaging:EnvironmentModules

[Vít Ondruch]

Dne 4.12.2012 15:54, Bohuslav Kabrda napsal(a):
>  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. 
I should also point out that you can try to use different rubies such as:

$ ruby _mri_ -v
$ ruby _jruby_ -v

Slavek, any indea if we could provide some help? Something like "ruby 
_help_" for example? However I am not sure if anybody is able to find 
this command :/


Vít

[Bohuslav Kabrda]

----- Original Message -----
>  Dne 4.12.2012 15:54, Bohuslav Kabrda napsal(a):
>  > 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.
>  
>  I should also point out that you can try to use different rubies such
>  as:
>  
>  $ ruby _mri_ -v
>  $ ruby _jruby_ -v
>  
>  Slavek, any indea if we could provide some help? Something like "ruby
>  _help_" for example? However I am not sure if anybody is able to find
>  this command :/
>  
>  
>  Vít 

I think I could add a hook for -h, that would first print help for the multiruby script
and then keep running for the used interpreter. So something like
$ ruby -h
This is Fedora's multiruby executable. You can blah blah blah...
Currently available runtimes: _mri_ (default), _jruby_

Selected: _mri_

<actual help for MRI>


I think this shouldn't affect the performance and it shouldn't damage user
experience.
Does that sound sane?

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[Miroslav Suchý]

On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
>  - 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 already have mechanism for that:

/etc/alternatives/*
update-alternatives(8)

/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be 
symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as 
/usr/bin/ruby).
And let update-alternatives manage the defaults.
-- 
Miroslav Suchy
Red Hat Systems Management Engineering

[Vít Ondruch]

Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
>  On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
> > - 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 already have mechanism for that:
>
>  /etc/alternatives/*
>  update-alternatives(8)
>
>  /usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be 
>  symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as 
>  /usr/bin/ruby).
>  And let update-alternatives manage the defaults. 
Yes, we have, but you need to have root privileges to use them. That is 
not cool. We believe that something like this script [1] could make 
better service.


Vít



[1] https://github.com/bkabrda/multiruby/blob/master/ruby

[Michal Fojtik]

On 12/13, Vít Ondruch wrote:
>  Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
>  >On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
>  >>- 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 already have mechanism for that:
>  >
>  >/etc/alternatives/*
>  >update-alternatives(8)
>  >
>  >/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which
>  >will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously
>  >known as /usr/bin/ruby).
>  >And let update-alternatives manage the defaults. 
Maybe a stupid idea, but why we just don't prefix the 'jruby' with
'j'?

So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem...
(jirb, jgem, etc...)

Then the shebang will be '#!/usr/bin/jruby' and the MRI version can
cooexist with the jruby.

  -- michal

>  
>  Yes, we have, but you need to have root privileges to use them. That
>  is not cool. We believe that something like this script [1] could
>  make better service.
>  
>  
>  Vít
>  
>  
>  
>  [1] https://github.com/bkabrda/multiruby/blob/master/ruby
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig 
-- 
Michal Fojtik <mfojtik(a)redhat.com&gt;
Deltacloud API, CloudForms

[Marek Jelen]

BTW, is it not the default behavior? There should be no jruby executable in the official
distro.

--
mj

On Dec 13, 2012, at 10:02 AM, Michal Fojtik wrote:

>  On 12/13, Vít Ondruch wrote:
> > Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
> >> On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
> >>> - 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 already have mechanism for that:
> >> 
> >> /etc/alternatives/*
> >> update-alternatives(8)
> >> 
> >> /usr/bin/ruby will be symlink to /etc/alternatives/ruby, which
> >> will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously
> >> known as /usr/bin/ruby).
> >> And let update-alternatives manage the defaults.
>  
>  Maybe a stupid idea, but why we just don't prefix the 'jruby' with
> 'j'?
>  
>  So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem...
>  (jirb, jgem, etc...)
>  
>  Then the shebang will be '#!/usr/bin/jruby' and the MRI version can
>  cooexist with the jruby.
>  
>   -- michal
>  
> > 
> > Yes, we have, but you need to have root privileges to use them. That
> > is not cool. We believe that something like this script [1] could
> > make better service.
> > 
> > 
> > Vít
> > 
> > 
> > 
> > [1] https://github.com/bkabrda/multiruby/blob/master/ruby
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>  
>  -- 
>  Michal Fojtik <mfojtik(a)redhat.com&gt;
>  Deltacloud API, CloudForms
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Dne 13.12.2012 10:02, Michal Fojtik napsal(a):
>  On 12/13, Vít Ondruch wrote:
> > Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
> >> On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
> >>> - 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 already have mechanism for that:
> >>
> >> /etc/alternatives/*
> >> update-alternatives(8)
> >>
> >> /usr/bin/ruby will be symlink to /etc/alternatives/ruby, which
> >> will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously
> >> known as /usr/bin/ruby).
> >> And let update-alternatives manage the defaults.
>  Maybe a stupid idea, but why we just don't prefix the 'jruby' with
> 'j'?
>
>  So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem...
>  (jirb, jgem, etc...)
>
>  Then the shebang will be '#!/usr/bin/jruby' and the MRI version can
>  cooexist with the jruby.
>
>     -- michal
>  
There is probably million of ruby scripts which has some #!ruby shebang. 
If only JRuby is on the system, they'll continue to work. Typical user 
does not care if he runs something by MRI, JRuby or Rubinius. S/he only 
cares if it works.

Actually, I am speaking about typical user, but I personally don't care. 
I don't care if I run gem2rpm by MRI or JRuby, if it works.


Vít

[Vít Ondruch]

Dne 13.12.2012 10:08, Marek Jelen napsal(a):
>  BTW, is it not the default behavior? There should be no jruby 
>  executable in the official distro.
>
>  --
>  mj
>  
I am not sure I understand to your point.

Vít

[Vít Ondruch]

Dne 13.12.2012 11:50, Vít Ondruch napsal(a):
>  Dne 13.12.2012 10:02, Michal Fojtik napsal(a):
> > On 12/13, Vít Ondruch wrote:
> >> Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
> >>> On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
> >>>> - 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 already have mechanism for that:
> >>>
> >>> /etc/alternatives/*
> >>> update-alternatives(8)
> >>>
> >>> /usr/bin/ruby will be symlink to /etc/alternatives/ruby, which
> >>> will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously
> >>> known as /usr/bin/ruby).
> >>> And let update-alternatives manage the defaults.
> > Maybe a stupid idea, but why we just don't prefix the 'jruby' with
> 'j'?
> >
> > So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem...
> > (jirb, jgem, etc...)
> >
> > Then the shebang will be '#!/usr/bin/jruby' and the MRI version can
> > cooexist with the jruby.
> >
> >    -- michal
> >
>
>  There is probably million of ruby scripts which has some #!ruby 
>  shebang. If only JRuby is on the system, they'll continue to work.  
* Of course
"they'll not work" I meant
>  Typical user does not care if he runs something by MRI, JRuby or 
>  Rubinius. S/he only cares if it works.
>
>  Actually, I am speaking about typical user, but I personally don't 
>  care. I don't care if I run gem2rpm by MRI or JRuby, if it works.
>
>
>  Vít
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Michal Fojtik]

On 12/13, Vít Ondruch wrote:
>  Dne 13.12.2012 10:02, Michal Fojtik napsal(a):
>  >On 12/13, Vít Ondruch wrote:
>  >>Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
>  >>>On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
>  >>>>- 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 already have mechanism for that:
>  >>>
>  >>>/etc/alternatives/*
>  >>>update-alternatives(8)
>  >>>
>  >>>/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which
>  >>>will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously
>  >>>known as /usr/bin/ruby).
>  >>>And let update-alternatives manage the defaults.
>  >Maybe a stupid idea, but why we just don't prefix the 'jruby' with
> 'j'?
>  >
>  >So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem...
>  >(jirb, jgem, etc...)
>  >
>  >Then the shebang will be '#!/usr/bin/jruby' and the MRI version can
>  >cooexist with the jruby.
>  >
>  >   -- michal
>  >
>  
>  There is probably million of ruby scripts which has some #!ruby
>  shebang. If only JRuby is on the system, they'll continue to work. 
Why you assume that this 'milion' of ruby scripts with MRI shebangs
will continue to work on jRuby (if only that ruby is installed in
system)?

>  Typical user does not care if he runs something by MRI, JRuby or
>  Rubinius. S/he only cares if it works. 
Well 'typical' user here is someone that wants to run his things on jRuby
in **production**, but develop using MRI (there are milion reasons why),

A typical user will never use Fedora MRI for development but will install
something like RVM or rbenv. Again, milion reasons why.

My point was to make it clear when I run something on my MRI ruby
(development/scripts) and when I run something on jRuby (production).

Btw. are there some personas or something for Ruby users in Fedora?
Like:

Bob, the system administrator that wants to have Puppet running.
Dave, web developer that wants to deploy apps on Fedora/RHEL

etc..

Having something like that will maybe help in future :-)

>  
>  Actually, I am speaking about typical user, but I personally don't
>  care. I don't care if I run gem2rpm by MRI or JRuby, if it works. 
You will probably find out in a while, that using 'scripts' on jRuby
isn't the best thing you do ;-) (like JVM boot time, etc).

  -- Michal

-- 
Michal Fojtik <mfojtik(a)redhat.com&gt;
Deltacloud API, CloudForms

[Vít Ondruch]

Dne 13.12.2012 13:15, Michal Fojtik napsal(a):
>  On 12/13, Vít Ondruch wrote:
> > Dne 13.12.2012 10:02, Michal Fojtik napsal(a):
> >> On 12/13, Vít Ondruch wrote:
> >>> Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
> >>>> On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
> >>>>> - 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 already have mechanism for that:
> >>>>
> >>>> /etc/alternatives/*
> >>>> update-alternatives(8)
> >>>>
> >>>> /usr/bin/ruby will be symlink to /etc/alternatives/ruby, which
> >>>> will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously
> >>>> known as /usr/bin/ruby).
> >>>> And let update-alternatives manage the defaults.
> >> Maybe a stupid idea, but why we just don't prefix the 'jruby' with
> 'j'?
> >>
> >> So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem...
> >> (jirb, jgem, etc...)
> >>
> >> Then the shebang will be '#!/usr/bin/jruby' and the MRI version can
> >> cooexist with the jruby.
> >>
> >>    -- michal
> >>
> > There is probably million of ruby scripts which has some #!ruby
> > shebang. If only JRuby is on the system, they'll continue to work.
>  Why you assume that this 'milion' of ruby scripts with MRI shebangs
>  will continue to work on jRuby (if only that ruby is installed in
>  system)? 
Shouldn't they? They are just Ruby. There might be definitely JRuby 
specific scripts or MRI specific scripts, but in 99% it is just bug IMO.

> > Typical user does not care if he runs something by MRI, JRuby or
> > Rubinius. S/he only cares if it works.
>  Well 'typical' user here is someone that wants to run his things on jRuby
>  in **production**, but develop using MRI (there are milion reasons why), 
Typical user install software using RPM, this is first premise. They 
have no custom scripts, no additional gems, etc.

>  A typical user will never use Fedora MRI for development but will install
>  something like RVM or rbenv. Again, milion reasons why. 
Typical user will not develop.

>  My point was to make it clear when I run something on my MRI ruby
>  (development/scripts) and when I run something on jRuby (production). 
There will be available jruby and ruby-mri (have not thought about the 
name yet) executables if you want to be sure.

>  Btw. are there some personas or something for Ruby users in Fedora?
>  Like:
>
>  Bob, the system administrator that wants to have Puppet running.
>  Dave, web developer that wants to deploy apps on Fedora/RHEL
>
>  etc..
>
>  Having something like that will maybe help in future :-) 
Oh please :)

> > Actually, I am speaking about typical user, but I personally don't
> > care. I don't care if I run gem2rpm by MRI or JRuby, if it works.
>  You will probably find out in a while, that using 'scripts' on jRuby
>  isn't the best thing you do ;-) (like JVM boot time, etc). 
That is true, but if you have at lease some ruby on your system, it is 
better to execute script slowly, then not execute at all.

>     -- Michal
>

[Michal Fojtik]

On 12/04, Vít Ondruch wrote:
>  Dne 4.12.2012 15:54, Bohuslav Kabrda napsal(a):
>  >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.
>  
>  I should also point out that you can try to use different rubies such as:
>  
>  $ ruby _mri_ -v
>  $ ruby _jruby_ -v 
How about:

$ RUBY_PLATFORM=mri ruby -v
$ RUBY_PLATFORM=jruby ruby -v

In this case you're not introducing cross-platform incompatibility for
shebangs ;-)

  -- Michal

>  
>  Slavek, any indea if we could provide some help? Something like
>  "ruby _help_" for example? However I am not sure if anybody is able
>  to find this command :/
>  
>  
>  Vít
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig 
-- 
Michal Fojtik <mfojtik(a)redhat.com&gt;
Deltacloud API, CloudForms

[Vít Ondruch]

Dne 13.12.2012 15:56, Michal Fojtik napsal(a):
>  On 12/04, Vít Ondruch wrote:
> >
> > I should also point out that you can try to use different rubies such as:
> >
> > $ ruby _mri_ -v
> > $ ruby _jruby_ -v
>  How about:
>
>  $ RUBY_PLATFORM=mri ruby -v
>  $ RUBY_PLATFORM=jruby ruby -v 
I would consider it as alternative. Who likes so much typing? And if you 
are alarmist, you should be afraid of possible env variable collision :)

>  In this case you're not introducing cross-platform incompatibility for
>  shebangs ;-) 
I am not afraid of shebangs incompatibility. I hope that if there will  
be JRuby specific code, nobody will come with #!/usr/bin/ruby _jruby_ 
shebang, but will go with !#/usr/bin/jruby. Not sure why s/he would use 
such shebang anyway.


Vít

[Miroslav Suchý]

On 12/13/2012 08:31 AM, Vít Ondruch wrote:
>  Yes, we have, but you need to have root privileges to use them. That
> is
>  not cool. 
Why is not cool?
If everything with #!ruby should be executed by jruby instead of cRuby, 
then I would expect that I need root privileges for this change.

-- 
Miroslav Suchy
Red Hat Systems Management Engineering

[Vít Ondruch]

Dne 8.1.2013 11:46, Miroslav Suchý napsal(a):
>  On 12/13/2012 08:31 AM, Vít Ondruch wrote:
> > Yes, we have, but you need to have root privileges to use them. That is
> > not cool.
>
>  Why is not cool?
>  If everything with #!ruby should be executed by jruby instead of 
>  cRuby, then I would expect that I need root privileges for this change.
>  
Yes, "if everything" and if system administrator should decide about it. 
E.g.

1) System administrator decides that he wants JRuby and JRuby only on 
the system, them he installs just JRuby and everything works. User 
cannot choose.
2) System administrator decides that hew wants to have available MRI, 
JRuby and Rubinius on the system and user can freely choose, then 
alternatives cannot help.

Vít