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

[Bohuslav Kabrda]

----- Original Message -----
> Hello,
> On Thu, Jan 24, 2013 at 7:58 AM, Bohuslav Kabrda <bkabrda at redhat.com>
> 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
Regards,
Bohuslav "Slavek" Kabrda.

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