Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation

[Jaroslav Reznik]

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. 

[1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_syst...
[2] https://github.com/bkabrda/rubypick 
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[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

[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. 
>  
>  [1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_syst...
>  [2] https://github.com/bkabrda/rubypick 
>  
As JRuby is setup to share pure ruby gems with ruby, I don't think this can
be approved (inlcuding the update to the jruby package to do this) until FPC
rules on whether it's okay for interpreters and languages which are not
completely compatible to share modules.  FPC will hopefully have quorum
tomorrow morning to meet.  If not, or if they have issues with the
guidelines, perhaps slavek and I can meet to try to figure out ways around
the issues.  I'll know more after the FPC meeting time tomorrow morning.

-Toshio

[Bohuslav Kabrda]

----- Original Message -----
>  On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote:
>  > 
>  > - 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.
>  > 
>  > [1]
>  > https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_syst...
>  > [2] https://github.com/bkabrda/rubypick
>  >
>  As JRuby is setup to share pure ruby gems with ruby, I don't think
>  this can
>  be approved (inlcuding the update to the jruby package to do this)
>  until FPC
>  rules on whether it's okay for interpreters and languages which are
>  not
>  completely compatible to share modules.  FPC will hopefully have
>  quorum
>  tomorrow morning to meet.  If not, or if they have issues with the
>  guidelines, perhaps slavek and I can meet to try to figure out ways
>  around
>  the issues.  I'll know more after the FPC meeting time tomorrow
>  morning.
>  
>  -Toshio
>   
(I'm CC'ing Charles Nutter and Thomas Enebo, the main JRuby guys, as hearing their
opinions on this would be highly beneficial.)
To explain why we want to share the pure Gems:
In Ruby world, JRuby is using what I would call a "pro-active" attitude. That
means that the default assumption is that all the pure Ruby Gems work with JRuby. If not,
then someone goes and fixes the stuff. Ruby-SIG is meaning to follow this path (as
upstream does). The other approach would obviously be assuming that the Gems don't
work and sharing them only if we're 100 % sure that they work completely the same. But
we can _never_ be sure of that (there is no way to test that). So to me, it seems that we
can either share all pure Ruby Gems and work with upstreams if something breaks (which is
not usual, big part of Ruby world is using JRuby without problems these days) or we cannot
share anything. I choose the first and I think that's a good step for Fedora to take.

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[Marcela Mašláňová]

On 01/23/2013 07:28 AM, Toshio Kuratomi wrote:
>  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.
> >
> > [1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_syst...
> > [2] https://github.com/bkabrda/rubypick
> >
>  As JRuby is setup to share pure ruby gems with ruby, I don't think this can
>  be approved (inlcuding the update to the jruby package to do this) until FPC
>  rules on whether it's okay for interpreters and languages which are not
>  completely compatible to share modules.  FPC will hopefully have quorum
>  tomorrow morning to meet.  If not, or if they have issues with the
>  guidelines, perhaps slavek and I can meet to try to figure out ways around
>  the issues.  I'll know more after the FPC meeting time tomorrow morning.
>
>  -Toshio
>
>
>  
Hi Toshio,
sharing Ruby gems between JRuby and rvm is supported by upstream, so why 
should we disagree with upstream? They know best what they can support. 
In Ruby world is JRuby used with ruby gems and other projects in Fedora 
can only benefit from this behaviour.

Marcela

[Richard W.M. Jones]

I think the more interesting question is what to do about extensions
(ie. not pure Ruby gems that contain C code).  Last time I looked
JRuby was pretty incompatible; in fact for libguestfs we recommend
that people use the *Java* bindings with JRuby ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

[Bohuslav Kabrda]

----- Original Message -----
>  I think the more interesting question is what to do about extensions
>  (ie. not pure Ruby gems that contain C code).  Last time I looked
>  JRuby was pretty incompatible; in fact for libguestfs we recommend
>  that people use the *Java* bindings with JRuby ...
>  
>  Rich.
>   
JRuby and Ruby won't share extensions. Extensions for Ruby will live in
%{_libdir}/gems/ruby, while extensions for JRuby will in %{_datadir}/gems/jruby (although
we decided not to actually ship any JRuby extension Gems for F19 as we want to take more
time to figure out the guidelines specifics around it).
JRuby is pretty incompatible with C extensions. In fact, guys from upstream told me that
they may even completely drop support for C extensions, as its very hard to maintain and
doesn't really bring significant benefits. That's why we don't want to do it
in Fedora.

>  --
>  Richard Jones, Virtualization Group, Red Hat
>  http://people.redhat.com/~rjones
>  Read my programming blog: http://rwmj.wordpress.com
>  Fedora now supports 80 OCaml packages (the OPEN alternative to F#) 
-- 
Regards,
Bohuslav "Slavek" Kabrda.

[Bill Nottingham]

Bohuslav Kabrda (bkabrda(a)redhat.com) said: 
>  JRuby and Ruby won't share extensions. Extensions for Ruby will
> live in %{_libdir}/gems/ruby, while extensions for JRuby will in %{_datadir}/gems/jruby
> (although we decided not to actually ship any JRuby extension Gems for F19 as we want to
> take more time to figure out the guidelines specifics around it).
>  JRuby is pretty incompatible with C extensions. In fact, guys from upstream told me that
> they may even completely drop support for C extensions, as its very hard to maintain and
> doesn't really bring significant benefits. That's why we don't want to do it
> in Fedora. 
So, thinking of this in terms of python (sorry, that's my experience), this
is the equivalent of an alternate python interpreter that can only use
.noarch python extensions/modules that don't depend on any archful python
modules?

How is an application author supposed to know which interpreter they can
use - do they have to recursively traverse their dependency stack first
before making a decision?

Bill

[Mo Morsi]

On 01/24/2013 11:07 AM, Bill Nottingham wrote:
>  Bohuslav Kabrda (bkabrda(a)redhat.com) said: 
> > JRuby and Ruby won't share extensions. Extensions for Ruby will live in
> %{_libdir}/gems/ruby, while extensions for JRuby will in %{_datadir}/gems/jruby (although
> we decided not to actually ship any JRuby extension Gems for F19 as we want to take more
> time to figure out the guidelines specifics around it).
> > JRuby is pretty incompatible with C extensions. In fact, guys from upstream told me
> that they may even completely drop support for C extensions, as its very hard to maintain
> and doesn't really bring significant benefits. That's why we don't want to do
> it in Fedora.
>  So, thinking of this in terms of python (sorry, that's my experience), this
>  is the equivalent of an alternate python interpreter that can only use
>  .noarch python extensions/modules that don't depend on any archful python
>  modules?
>
>  How is an application author supposed to know which interpreter they can
>  use - do they have to recursively traverse their dependency stack first
>  before making a decision?
>
>  Bill
>  
Most popular gems w/ native extensions support the big interpreters,
namely MRI (the official ruby) and JRuby. AFAIK the other smaller
interpreters offer compliance w/ at least one of these.

Yes it is true that there are gems that do not offer support for both,
but it isn't too common. There used to be a site isitjruby.com that
served as a community driven knowledge base for jruby-compatability, but
it no longer exists.

IMO this is a great selling point for Fedora to the upstream Ruby
development community, use our Ruby stack and things will "just work"
(tm). The value we offer to upstream ruby via the Fedora stack can be
seen at http://isitfedoraruby.com

  -Mo

[Toshio Kuratomi]

On Wed, Jan 23, 2013 at 12:44:16PM +0100, Marcela Mašláňová wrote:
>  On 01/23/2013 07:28 AM, Toshio Kuratomi wrote:
>  >As JRuby is setup to share pure ruby gems with ruby, I don't think this can
>  >be approved (inlcuding the update to the jruby package to do this) until FPC
>  >rules on whether it's okay for interpreters and languages which are not
>  >completely compatible to share modules.  FPC will hopefully have quorum
>  >tomorrow morning to meet.  If not, or if they have issues with the
>  >guidelines, perhaps slavek and I can meet to try to figure out ways around
>  >the issues.  I'll know more after the FPC meeting time tomorrow morning.
>  >
>  >-Toshio
>  >
>  >
>  >
>  Hi Toshio,
>  sharing Ruby gems between JRuby and rvm is supported by upstream, so
>  why should we disagree with upstream? They know best what they can
>  support. In Ruby world is JRuby used with ruby gems and other
>  projects in Fedora can only benefit from this behaviour.
>   
Hey Marcela, sharing of code by language interpreters that are not fully
compatible with each other is a big change to how Fedora ships packages.
This needs to be considered by FPC to decide if it's okay to do so and if
the methods suggested protect user's who are just trying to install working
versions of the applications.

Personally, I'm leaning towards liking the concept.  Agreeing with the idea
of a script to multiplex between different interpreters for applications.
And thinking that the Provides and Requires proposal is insufficient.  But
like I say, I don't know what the rest of FPC thinks.  So I don't yet know
if we'll need to make small alterations to the Provides and Requires
proposal or throw it out and figure out a different way to do it (or if the
whole concept will be deemed unfit).

I'll know more after the meeting.

-Toshio

[Toshio Kuratomi]

On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote:
>   What should "/usr/bin/ruby" point to?
>  
Took a look just to make sure -- this portion needs to get into the new
packaging guidelines.  Maybe in the Applicatoins section?

-Toshio

[Miloslav Trmač]

On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  = Features/JRuby 1.7 =
>  https://fedoraproject.org/wiki/Features/JRuby_1.7 
>   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. 
What problem are the _mri_/_jruby_ parameters solving?
a) If a script or command-line user requires a specific interpreter,
it can just refer to a path of the specific interpreter directly;
using /usr/bin/ruby magic_parameter seems to provide no advantage.
b) If a script or command-line user doesn't care which interpreter is
used, it doesn't need the magic parameter either.
What am I missing?

Changing the semantics of command-line arguments in unexpected ways
really worries me - it has security implications; e.g. creating a file
named _jruby_ would change the semantics of running "my_script *".  If
it really is necessary to have a switch that alters the behavior of
/usr/bin/ruby, could it be an environment variable instead?  It is
usually more difficult for an attacker to manipulate the process
environment than file names.
   Mirek

[Bohuslav Kabrda]

----- Original Message -----
>  On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt;
>  wrote:
>  > = Features/JRuby 1.7 =
>  > https://fedoraproject.org/wiki/Features/JRuby_1.7
>  
>  >  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.
>  
>  What problem are the _mri_/_jruby_ parameters solving?
>  a) If a script or command-line user requires a specific interpreter,
>  it can just refer to a path of the specific interpreter directly;
>  using /usr/bin/ruby magic_parameter seems to provide no advantage.
>  b) If a script or command-line user doesn't care which interpreter is
>  used, it doesn't need the magic parameter either.
>  What am I missing?
>   
- So let's consider creating a new Rails application. You create it using "rails
new app". Rails have shebang #!/usr/bin/ruby, so that would imply always using MRI
and you'd have to figure out how to actually run it with JRuby. The problem here is,
that a Rails application generated by Ruby and JRuby looks differently. Specifically,
their Gemfiles are different - the implementation independent Gems are the same, but
extension Gems (e.g. DB drivers, JS runtime wrapper) are not the same.
- The user might not care which interpreter is used, but a developer wanting to test the
application under MRI/JRuby appreciates a fast and easy way how to test under both.

>  Changing the semantics of command-line arguments in unexpected ways
>  really worries me - it has security implications; e.g. creating a
>  file
>  named _jruby_ would change the semantics of running "my_script *". 
It's true, that it would run actually run _jruby_ and ignore the file, although
I'm not sure what security risks that brings. Could you be more specific?

>   If
>  it really is necessary to have a switch that alters the behavior of
>  /usr/bin/ruby, could it be an environment variable instead?  It is
>  usually more difficult for an attacker to manipulate the process
>  environment than file names. 
I've added environment variable support recently, I'll mention it on the feature
page.

>     Mirek
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
-- 
Regards,
Bohuslav "Slavek" Kabrda.

[Miloslav Trmač]

Hello,
On Thu, Jan 24, 2013 at 7:58 AM, Bohuslav Kabrda <bkabrda(a)redhat.com&gt; wrote:
>  ----- Original Message -----
> > What problem are the _mri_/_jruby_ parameters solving?
> > a) If a script or command-line user requires a specific interpreter,
> > it can just refer to a path of the specific interpreter directly;
> > using /usr/bin/ruby magic_parameter seems to provide no advantage.
> > b) If a script or command-line user doesn't care which interpreter is
> > used, it doesn't need the magic parameter either.
> > What am I missing?
> >
>
>  - So let's consider creating a new Rails application. You create it using "rails
> new app". Rails have shebang #!/usr/bin/ruby, so that would imply always using MRI
> and you'd have to figure out how to actually run it with JRuby. The problem here is,
> that a Rails application generated by Ruby and JRuby looks differently. Specifically,
> their Gemfiles are different - the implementation independent Gems are the same, but
> extension Gems (e.g. DB drivers, JS runtime wrapper) are not the same.
>  - The user might not care which interpreter is used, but a developer wanting to test the
> application under MRI/JRuby appreciates a fast and easy way how to test under both.
That's definitely a valid use case; why is it better for the user to
run (./script/rails _jruby_) instead of (/usr/bin/jruby
./script/rails)?  The latter should be more portable, and requires no
effort to implement.

> > Changing the semantics of command-line arguments in unexpected
> ways
> > really worries me - it has security implications; e.g. creating a
> > file
> > named _jruby_ would change the semantics of running "my_script *".
>
>  It's true, that it would run actually run _jruby_ and ignore the file, although
> I'm not sure what security risks that brings. Could you be more specific? 
I don't really have a specific concern; it just doesn't "feel right"
to override application behavior this way (and, from a security point
of view, "composition kills" - having harmless corner cases in
packages A, B, C may mean that there is a vulnerability when A,B,C are
used together).

Looking at the rubypick script, it seems to actually override "-h",
which would be very user-noticeable.
    Mirek

[Bohuslav Kabrda]

----- Original Message -----
>  Hello,
>  On Thu, Jan 24, 2013 at 7:58 AM, Bohuslav Kabrda <bkabrda(a)redhat.com&gt;
>  wrote:
>  > ----- Original Message -----
>  >> What problem are the _mri_/_jruby_ parameters solving?
>  >> a) If a script or command-line user requires a specific
>  >> interpreter,
>  >> it can just refer to a path of the specific interpreter directly;
>  >> using /usr/bin/ruby magic_parameter seems to provide no advantage.
>  >> b) If a script or command-line user doesn't care which interpreter
>  >> is
>  >> used, it doesn't need the magic parameter either.
>  >> What am I missing?
>  >>
>  >
>  > - So let's consider creating a new Rails application. You create it
>  > using "rails new app". Rails have shebang #!/usr/bin/ruby, so that
>  > would imply always using MRI and you'd have to figure out how to
>  > actually run it with JRuby. The problem here is, that a Rails
>  > application generated by Ruby and JRuby looks differently.
>  > Specifically, their Gemfiles are different - the implementation
>  > independent Gems are the same, but extension Gems (e.g. DB
>  > drivers, JS runtime wrapper) are not the same.
>  > - The user might not care which interpreter is used, but a
>  > developer wanting to test the application under MRI/JRuby
>  > appreciates a fast and easy way how to test under both.
>  
>  That's definitely a valid use case; why is it better for the user to
>  run (./script/rails _jruby_) instead of (/usr/bin/jruby
>  ./script/rails)?  The latter should be more portable, and requires no
>  effort to implement.
>   
To me, typing "rails _jruby_" is more comfortable than "jruby
/usr/bin/rails" (yep, I agree that this is a matter of opinion). Also, I'm not
sure whether I mentioned a Ruby way of running certain versions of Gems executables, so
I'll mention it again [1] (scroll a bit lower to see invoking specific version of rake
with "rake _0.7.3_"). This is how we got the idea in the first place and why we
think it would be quite convenient for ruby devs.

>  >> Changing the semantics of command-line arguments in
> unexpected
>  >> ways
>  >> really worries me - it has security implications; e.g. creating a
>  >> file
>  >> named _jruby_ would change the semantics of running "my_script *".
>  >
>  > It's true, that it would run actually run _jruby_ and ignore the
>  > file, although I'm not sure what security risks that brings. Could
>  > you be more specific?
>  
>  I don't really have a specific concern; it just doesn't "feel right"
>  to override application behavior this way (and, from a security point
>  of view, "composition kills" - having harmless corner cases in
>  packages A, B, C may mean that there is a vulnerability when A,B,C
>  are
>  used together).
>  
>  Looking at the rubypick script, it seems to actually override "-h",
>  which would be very user-noticeable. 
Yes, the idea is to also provide the info about rubypick when using ruby -h, but that
doesn't break anything. Ruby's help is printed after rubypick's anyway, so I
really don't see what harm this may do.

>      Mirek
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] http://guides.rubygems.org/command-reference/#gem_install

[Vít Ondruch]

Dne 23.1.2013 18:59, Miloslav Trmač napsal(a):
>  On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt; wrote:
> > = Features/JRuby 1.7 =
> > https://fedoraproject.org/wiki/Features/JRuby_1.7
> >   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. 
I'll try elaborate why we chose this approach.

>  What problem are the _mri_/_jruby_ parameters solving? 
Generally, we are trying to get into Fedora more Ruby interpreters, we 
are currently speaking about Ruby MRI, JRuby and Rubinius in near 
future. Therefore, we would like to allow the user to have the one he 
chose or all of them if (s)he wants. For that, we need to have something 
which can always interpret script with #!/usr/bin/ruby and that is going 
to be our rubypick, which will be always capable to select the best Ruby 
interpreted available on the computer.

>  a) If a script or command-line user requires a specific interpreter,
>  it can just refer to a path of the specific interpreter directly;
>  using /usr/bin/ruby magic_parameter seems to provide no advantage. 
Yes, you are right. Instead of just "rake" user can run "jruby -S
rake" 
to run rake by JRuby. To be honest, I needed quite a lot of thinking to 
realize that this is also possible.

This is just another convenient option IMO and it is actually nothing 
new, because you can run "rake _0.8.7_" to specify, that you'd like to 
run Rake of that specific version. So we just build on this.

>  b) If a script or command-line user doesn't care which
> interpreter is
>  used, it doesn't need the magic parameter either.
>  What am I missing? 
Yes, as long as you don't care, you don't need magic parameter.

>  Changing the semantics of command-line arguments in unexpected ways
>  really worries me - it has security implications; e.g. creating a file
>  named _jruby_ would change the semantics of running "my_script *".  If
>  it really is necessary to have a switch that alters the behavior of
>  /usr/bin/ruby, could it be an environment variable instead?  It is
>  usually more difficult for an attacker to manipulate the process
>  environment than file names. 
Yes, I agree that you should be worried:

$ ls *
ls: cannot access *: No such file or directory
$ touch -- -l
$ ls *
total 0
-rw-rw-r--. 1 user user 0 Jan 24 10:10 -l

But as my example shows, it is nothing new. And as Slavek wrote, 
environment variables are already supported.



Vít

[Miloslav Trmač]

On Thu, Jan 24, 2013 at 10:21 AM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
> > What problem are the _mri_/_jruby_ parameters solving?
>
>  Generally, we are trying to get into Fedora more Ruby interpreters, we are
>  currently speaking about Ruby MRI, JRuby and Rubinius in near future.
>  Therefore, we would like to allow the user to have the one he chose or all
>  of them if (s)he wants. For that, we need to have something which can always
>  interpret script with #!/usr/bin/ruby and that is going to be our rubypick,
>  which will be always capable to select the best Ruby interpreted available
>  on the computer. 
Right, having a single shebang line that "always works" is a valid
concern.  That doesn't necessarily mean that this /usr/bin/ruby script
should handle some command-line arguments specially.


> > Changing the semantics of command-line arguments in unexpected
> ways
> > really worries me - it has security implications; e.g. creating a file
> > named _jruby_ would change the semantics of running "my_script *".  If
> > it really is necessary to have a switch that alters the behavior of
> > /usr/bin/ruby, could it be an environment variable instead?  It is
> > usually more difficult for an attacker to manipulate the process
> > environment than file names.
>
>  Yes, I agree that you should be worried:
>
>  $ ls *
>  ls: cannot access *: No such file or directory
>  $ touch -- -l
>  $ ls *
>  total 0
>  -rw-rw-r--. 1 user user 0 Jan 24 10:10 -l
>
>  But as my example shows, it is nothing new. And as Slavek wrote, environment
>  variables are already supported. 
When viewed as a shell behavior, it's nothing new.  The thing that is
new is the response of the application (e.g. rubypick taking over -h /
--help as I mentioned in the other mail).


This is ultimately up to FPC, isn't it?  Anyway, let me suggest that
the environment variable approach is better overall (similar UI, and
unlike command-line arguments environment variables are automatically
propagated to child processes), the command-line arguments are more
intrusive and risky, so using _only_ environment variables would
handle all use cases that have been mentioned so far and avoid the
major risks.
    Mirek

[Miloslav Trmač]

On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; 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 
>  Contingency Plan
>
>  Reverting to the previous behaviour will always be doable very easily, no harm will be
> done. 
"Very easily" is a judgement, not a description.  Please describe
what
exactly would be reverted.
   Mirek

[Bohuslav Kabrda]

----- Original Message -----
>  On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt;
>  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
>  
>  > Contingency Plan
>  >
>  > Reverting to the previous behaviour will always be doable very
>  > easily, no harm will be done.
>  "Very easily" is a judgement, not a description.  Please describe
>  what
>  exactly would be reverted. 
All the special behaviour (sharing Gems, rubypick). The new version should hit Fedora
either way and in this case it would work exactly the way JRuby has been working up until
now.

>     Mirek
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
-- 
Regards,
Bohuslav "Slavek" Kabrda.