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

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

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