----- Original Message ----- > Hello, > On Thu, Jan 24, 2013 at 7:58 AM, Bohuslav Kabrda <bkab...@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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Regards, Bohuslav "Slavek" Kabrda. [1] http://guides.rubygems.org/command-reference/#gem_install -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
