Ruby vs. JRuby - alternatives or not?

[Bohuslav Kabrda]

Hi all,
as I'm working on packaging new JRuby for F19, I've started thinking about
approach to coexistence of JRuby and cRuby - and I'd like to hear some opinions on
that.
On the first look, cRuby and JRuby seem to be an appropriate candidates for using
alternatives (which solves the problem of automatically generated dependencies from
shebangs and switching interpreters by root). But - thinking of it further, I'm not
sure whether cRuby and JRuby are alternatives. Reasons:

1. extension gems - there are gems with extensions
a) only for cRuby
b) only for JRuby
c) for both implementations.
Obviously, most of the cRuby-only extension gems are only usable with cRuby and vice versa
for JRuby (exceptions are gems that contain pure Ruby fallback when extension cannot be
loaded). For these extension gems, cRuby and JRuby are not alternatives, AFAICS.
2. pure Ruby gems using cRuby specific functions - some Ruby functions, for example
fork(), cannot be used on JRuby, because JRuby doesn't support fork() - so if a gem
uses fork, it only works on cRuby.

So cRuby and JRuby are mostly alternatives, but not completely. Therefore we (ruby-sig
folks) came up with an idea that we call multiruby [1], which allows user (a user who
knows what he's doing - for RPM packaged applications, packager will choose how to run
them, possibly modifying shebangs) to choose the interpreter on invocation. The intepreter
defaults to cRuby (also, compared to alternatives, this approach brings the benefit on
non-root user being able to choose/switch the interpreter). In this scheme, /usr/bin/ruby
would be a shell script that would route the commands either to /usr/bin/ruby-mri or
/usr/bin/jruby. I know that this is no standard mechanism, but it doesn't break any
expectations and brings some interesting functionality.

For example
ruby foo.rb # behaves as it now does
gem install foo # behaves as it now does
ruby _jruby_ foo.rb # invokes foo.rb with jruby
gem _jruby_ install foo # runs "gem install" with jruby

The inspiration for this approach is actually taken from RubyGems binary wrappers (as
documented in [2]). The wrappers let you choose gem version on the wrapper execution, e.g.
"rake _0.7.3_" will run rake 0.7.3, so the multiruby concept would not be
anything strange to Ruby folks.
Thoughts? Would this be an acceptable approach?
Thanks.

[1] https://github.com/bkabrda/multiruby
[2] http://guides.rubygems.org/command-reference/#gem_install, section about wrappers

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[Miroslav Suchý]

On 01/07/2013 12:23 PM, Bohuslav Kabrda wrote:
>  On the first look, cRuby and JRuby seem to be an appropriate
> candidates for using alternatives (which solves the problem of automatically generated
> dependencies from shebangs and switching interpreters by root). But - thinking of it
> further, I'm not sure whether cRuby and JRuby are alternatives. Reasons:
>
>  1. extension gems - there are gems with extensions
>  a) only for cRuby
>  b) only for JRuby
>  c) for both implementations.
>  Obviously, most of the cRuby-only extension gems are only usable with cRuby and vice
> versa for JRuby (exceptions are gems that contain pure Ruby fallback when extension cannot
> be loaded). For these extension gems, cRuby and JRuby are not alternatives, AFAICS.
The same apply for jre, mta and other alternatives.
Useing the first: there is general alternative "jre", but for sure there 
are JARs which only works with Java 1.5 some only with 1.7, some only 
with Sun, others only with IBM... Life is hard.

+1

>  2. pure Ruby gems using cRuby specific functions - some Ruby
> functions, for example fork(), cannot be used on JRuby, because JRuby doesn't support
> fork() - so if a gem uses fork, it only works on cRuby.
>
>  So cRuby and JRuby are mostly alternatives, but not completely. Therefore we (ruby-sig
> folks) came up with an idea that we call multiruby [1], which allows user (a user who
> knows what he's doing - for RPM packaged applications, packager will choose how to run
> them, possibly modifying shebangs) to choose the interpreter on invocation. The intepreter
> defaults to cRuby (also, compared to alternatives, this approach brings the benefit on
> non-root user being able to choose/switch the interpreter). In this scheme, /usr/bin/ruby
> would be a shell script that would route the commands either to /usr/bin/ruby-mri or
> /usr/bin/jruby. I know that this is no standard mechanism, but it doesn't break any
> expectations and brings some interesting functionality. 
-1

This is IMHO bad move. This move the decision on what alternative will 
be used from sysadmin to packagers. And I-as-sysadmin want to be 
responsible for that.

-- 
Miroslav Suchy
Red Hat Systems Management Engineering

[Toshio Kuratomi]

On Mon, Jan 07, 2013 at 06:23:34AM -0500, Bohuslav Kabrda wrote:
>  Hi all,
>  as I'm working on packaging new JRuby for F19, I've started thinking about
> approach to coexistence of JRuby and cRuby - and I'd like to hear some opinions on
> that.
>  On the first look, cRuby and JRuby seem to be an appropriate candidates for using
> alternatives (which solves the problem of automatically generated dependencies from
> shebangs and switching interpreters by root). But - thinking of it further, I'm not
> sure whether cRuby and JRuby are alternatives. Reasons:
>  
>  1. extension gems - there are gems with extensions
>  a) only for cRuby
>  b) only for JRuby
>  c) for both implementations.
>  Obviously, most of the cRuby-only extension gems are only usable with cRuby and vice
> versa for JRuby (exceptions are gems that contain pure Ruby fallback when extension cannot
> be loaded). For these extension gems, cRuby and JRuby are not alternatives, AFAICS.
>  2. pure Ruby gems using cRuby specific functions - some Ruby functions, for example
> fork(), cannot be used on JRuby, because JRuby doesn't support fork() - so if a gem
> uses fork, it only works on cRuby.
>  
>  So cRuby and JRuby are mostly alternatives, but not completely. Therefore we (ruby-sig
> folks) came up with an idea that we call multiruby [1], which allows user (a user who
> knows what he's doing - for RPM packaged applications, packager will choose how to run
> them, possibly modifying shebangs) to choose the interpreter on invocation. The intepreter
> defaults to cRuby (also, compared to alternatives, this approach brings the benefit on
> non-root user being able to choose/switch the interpreter). In this scheme, /usr/bin/ruby
> would be a shell script that would route the commands either to /usr/bin/ruby-mri or
> /usr/bin/jruby. I know that this is no standard mechanism, but it doesn't break any
> expectations and brings some interesting functionality.
>  
>  For example
>  ruby foo.rb # behaves as it now does
>  gem install foo # behaves as it now does
>  ruby _jruby_ foo.rb # invokes foo.rb with jruby
>  gem _jruby_ install foo # runs "gem install" with jruby
>  
>  The inspiration for this approach is actually taken from RubyGems binary wrappers (as
> documented in [2]). The wrappers let you choose gem version on the wrapper execution, e.g.
> "rake _0.7.3_" will run rake 0.7.3, so the multiruby concept would not be
> anything strange to Ruby folks.
>  Thoughts? Would this be an acceptable approach?
>  
I don't think this would be acceptable.  But there might be specific use
cases that you want to solve that could be solved in similar ways.

As you say, alternatives definitely does not fit here.  Environment modules
may be able to fit some of the use cases, though.

I'm also not 100% against this idea.  Having a list of use cases would
probably be the place to start evaluating this.

-Toshio

[Bohuslav Kabrda]

----- Original Message -----
>  On Mon, Jan 07, 2013 at 06:23:34AM -0500, Bohuslav Kabrda wrote:
>  > Hi all,
>  > as I'm working on packaging new JRuby for F19, I've started
>  > thinking about approach to coexistence of JRuby and cRuby - and
>  > I'd like to hear some opinions on that.
>  > On the first look, cRuby and JRuby seem to be an appropriate
>  > candidates for using alternatives (which solves the problem of
>  > automatically generated dependencies from shebangs and switching
>  > interpreters by root). But - thinking of it further, I'm not sure
>  > whether cRuby and JRuby are alternatives. Reasons:
>  > 
>  > 1. extension gems - there are gems with extensions
>  > a) only for cRuby
>  > b) only for JRuby
>  > c) for both implementations.
>  > Obviously, most of the cRuby-only extension gems are only usable
>  > with cRuby and vice versa for JRuby (exceptions are gems that
>  > contain pure Ruby fallback when extension cannot be loaded). For
>  > these extension gems, cRuby and JRuby are not alternatives,
>  > AFAICS.
>  > 2. pure Ruby gems using cRuby specific functions - some Ruby
>  > functions, for example fork(), cannot be used on JRuby, because
>  > JRuby doesn't support fork() - so if a gem uses fork, it only
>  > works on cRuby.
>  > 
>  > So cRuby and JRuby are mostly alternatives, but not completely.
>  > Therefore we (ruby-sig folks) came up with an idea that we call
>  > multiruby [1], which allows user (a user who knows what he's doing
>  > - for RPM packaged applications, packager will choose how to run
>  > them, possibly modifying shebangs) to choose the interpreter on
>  > invocation. The intepreter defaults to cRuby (also, compared to
>  > alternatives, this approach brings the benefit on non-root user
>  > being able to choose/switch the interpreter). In this scheme,
>  > /usr/bin/ruby would be a shell script that would route the
>  > commands either to /usr/bin/ruby-mri or /usr/bin/jruby. I know
>  > that this is no standard mechanism, but it doesn't break any
>  > expectations and brings some interesting functionality.
>  > 
>  > For example
>  > ruby foo.rb # behaves as it now does
>  > gem install foo # behaves as it now does
>  > ruby _jruby_ foo.rb # invokes foo.rb with jruby
>  > gem _jruby_ install foo # runs "gem install" with jruby
>  > 
>  > The inspiration for this approach is actually taken from RubyGems
>  > binary wrappers (as documented in [2]). The wrappers let you
>  > choose gem version on the wrapper execution, e.g. "rake _0.7.3_"
>  > will run rake 0.7.3, so the multiruby concept would not be
>  > anything strange to Ruby folks.
>  > Thoughts? Would this be an acceptable approach?
>  >
>  I don't think this would be acceptable.  But there might be specific
>  use
>  cases that you want to solve that could be solved in similar ways.
>  
>  As you say, alternatives definitely does not fit here.  Environment
>  modules
>  may be able to fit some of the use cases, though.
>   
I've been thinking about environment modules a lot, but there are some problems I can
see right now (if I understand the whole concept correctly):
- #!/usr/bin/ruby shebang will cause automatically generated RPM dependency - how will the
environment modules work with this? Only one interpreter will provide /usr/bin/ruby,
causing this interpreter to be drawn in when installing something with that shebang. And
AFAICS it is even appropriate for a package using env modules for "ruby"
executable to provide /usr/bin/ruby.
- again, the shebang - if I have a "gem" command, that has this shebang, it will
try to use /usr/bin/ruby - if it's not found it will fail, if found, it will use
whatever /usr/bin/ruby points to (but nothing else).
Both of these cases would probably be solvable by replacing all shebangs with /usr/bin/env
ruby. But we can't do that for non-RPM gems/apps that users will install - and they
will.

>  I'm also not 100% against this idea.  Having a list of use cases
>  would
>  probably be the place to start evaluating this.
>   
The main usecase is allowing users to have arbitrary Ruby implementations (possibly
excluding cRuby) installed and have /usr/bin/ruby still provide the functionality of ruby
interpreter + solving the shebang problems above and providing an easy way to switch the
implementations. So basically developers are the target, users of applications
wouldn't be affected by this (as I've mentioned, all of the previous functionality
is preserved).

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