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

[Bohuslav Kabrda]

----- Original Message -----
> On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik <jreznik at redhat.com>
> 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
Regards,
Bohuslav "Slavek" Kabrda.