Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
- 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
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
Dne 23.1.2013 18:59, Miloslav Trmač napsal(a): On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik jrez...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
Bohuslav Kabrda (bkab...@redhat.com) said:
JRuby and Ruby won't share extensions. Extensions for Ruby will live in
%{_libdir}/gems/ruby, while extensions for JRuby will in
%{_datadir}/gems/jruby (although we decided not to actually ship any JRuby
extension Gems for F19 as we want to take more time to figure out the
guidelines specifics around it).
JRuby is pretty incompatible with C extensions. In fact, guys from upstream
told me that they may even completely drop support for C extensions, as its
very hard to maintain and doesn't really bring significant benefits. That's
why we don't want to do it in Fedora.
So, thinking of this in terms of python (sorry, that's my experience), this
is the equivalent of an alternate python interpreter that can only use
.noarch python extensions/modules that don't depend on any archful python
modules?
How is an application author supposed to know which interpreter they can
use - do they have to recursively traverse their dependency stack first
before making a decision?
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
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. 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. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On Thu, Jan 24, 2013 at 10:21 AM, Vít Ondruch vondr...@redhat.com wrote: 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. Right, having a single shebang line that always works is a valid concern. That doesn't necessarily mean that this /usr/bin/ruby script should handle some command-line arguments specially. 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. When viewed as a shell behavior, it's nothing new. The thing that is new is the response of the application (e.g. rubypick taking over -h / --help as I mentioned in the other mail). This is ultimately up to FPC, isn't it? Anyway, let me suggest that the environment variable approach is better overall (similar UI, and unlike command-line arguments environment variables are automatically propagated to child processes), the command-line arguments are more intrusive and risky, so using _only_ environment variables would handle all use cases that have been mentioned so far and avoid the major risks. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On 01/24/2013 11:07 AM, Bill Nottingham wrote:
Bohuslav Kabrda (bkab...@redhat.com) said:
JRuby and Ruby won't share extensions. Extensions for Ruby will live in
%{_libdir}/gems/ruby, while extensions for JRuby will in
%{_datadir}/gems/jruby (although we decided not to actually ship any JRuby
extension Gems for F19 as we want to take more time to figure out the
guidelines specifics around it).
JRuby is pretty incompatible with C extensions. In fact, guys from upstream
told me that they may even completely drop support for C extensions, as its
very hard to maintain and doesn't really bring significant benefits. That's
why we don't want to do it in Fedora.
So, thinking of this in terms of python (sorry, that's my experience), this
is the equivalent of an alternate python interpreter that can only use
.noarch python extensions/modules that don't depend on any archful python
modules?
How is an application author supposed to know which interpreter they can
use - do they have to recursively traverse their dependency stack first
before making a decision?
Bill
Most popular gems w/ native extensions support the big interpreters,
namely MRI (the official ruby) and JRuby. AFAIK the other smaller
interpreters offer compliance w/ at least one of these.
Yes it is true that there are gems that do not offer support for both,
but it isn't too common. There used to be a site isitjruby.com that
served as a community driven knowledge base for jruby-compatability, but
it no longer exists.
IMO this is a great selling point for Fedora to the upstream Ruby
development community, use our Ruby stack and things will just work
(tm). The value we offer to upstream ruby via the Fedora stack can be
seen at http://isitfedoraruby.com
-Mo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
- Original Message - On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote: - Changes in packaging None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of the box, but packaging of Gems with JRuby extensions is turning out to be very complicated, so the guidelines for it will be postponed to next release (as well as the actual packaging). Users will be still able to install Gems with JRuby extensions, both system-wide (into /usr/local/) and into their home directories. [1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb [2] https://github.com/bkabrda/rubypick As JRuby is setup to share pure ruby gems with ruby, I don't think this can be approved (inlcuding the update to the jruby package to do this) until FPC rules on whether it's okay for interpreters and languages which are not completely compatible to share modules. FPC will hopefully have quorum tomorrow morning to meet. If not, or if they have issues with the guidelines, perhaps slavek and I can meet to try to figure out ways around the issues. I'll know more after the FPC meeting time tomorrow morning. -Toshio (I'm CC'ing Charles Nutter and Thomas Enebo, the main JRuby guys, as hearing their opinions on this would be highly beneficial.) To explain why we want to share the pure Gems: In Ruby world, JRuby is using what I would call a pro-active attitude. That means that the default assumption is that all the pure Ruby Gems work with JRuby. If not, then someone goes and fixes the stuff. Ruby-SIG is meaning to follow this path (as upstream does). The other approach would obviously be assuming that the Gems don't work and sharing them only if we're 100 % sure that they work completely the same. But we can _never_ be sure of that (there is no way to test that). So to me, it seems that we can either share all pure Ruby Gems and work with upstreams if something breaks (which is not usual, big part of Ruby world is using JRuby without problems these days) or we cannot share anything. I choose the first and I think that's a good step for Fedora to take. -- Regards, Bohuslav Slavek Kabrda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On 01/23/2013 07:28 AM, Toshio Kuratomi wrote: On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/JRuby 1.7 = https://fedoraproject.org/wiki/Features/JRuby_1.7 * Detailed description: Transition to JRuby 1.7 will consist of 3 basic steps: - Updating packages Most of the packages that JRuby depends on are in Fedora just because of JRuby, so they can be safely updated. Some dependencies are shared with other packages, so they will have to be discussed with their owners (see #Scope). - Integration with Fedora Normally, each Ruby implementations ships with its own copy of RubyGems library. This is wrong because a) it's bundling, b) there is no reason why multiple Ruby implementations wouldn't be able to share one RubyGems library. There used to be some differencies in JRuby's copy of RubyGems, but the JRuby upstream has been very cooperative and managed to get them all merged into upstream RubyGems. The integration will require changing Fedora's operating_system.rb (place for distro-specific defaults for RubyGems). This change will result into all Gems with binary extensions having to be recompiled, as the binary extension placement will change. See [1] for current operating_system.rb look and its changes from F18. 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. - Changes in packaging None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of the box, but packaging of Gems with JRuby extensions is turning out to be very complicated, so the guidelines for it will be postponed to next release (as well as the actual packaging). Users will be still able to install Gems with JRuby extensions, both system-wide (into /usr/local/) and into their home directories. [1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb [2] https://github.com/bkabrda/rubypick As JRuby is setup to share pure ruby gems with ruby, I don't think this can be approved (inlcuding the update to the jruby package to do this) until FPC rules on whether it's okay for interpreters and languages which are not completely compatible to share modules. FPC will hopefully have quorum tomorrow morning to meet. If not, or if they have issues with the guidelines, perhaps slavek and I can meet to try to figure out ways around the issues. I'll know more after the FPC meeting time tomorrow morning. -Toshio Hi Toshio, sharing Ruby gems between JRuby and rvm is supported by upstream, so why should we disagree with upstream? They know best what they can support. In Ruby world is JRuby used with ruby gems and other projects in Fedora can only benefit from this behaviour. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
I think the more interesting question is what to do about extensions (ie. not pure Ruby gems that contain C code). Last time I looked JRuby was pretty incompatible; in fact for libguestfs we recommend that people use the *Java* bindings with JRuby ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote: What should /usr/bin/ruby point to? Took a look just to make sure -- this portion needs to get into the new packaging guidelines. Maybe in the Applicatoins section? -Toshio pgpFRnqNwXwpf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On Wed, Jan 23, 2013 at 12:44:16PM +0100, Marcela Mašláňová wrote: On 01/23/2013 07:28 AM, Toshio Kuratomi wrote: As JRuby is setup to share pure ruby gems with ruby, I don't think this can be approved (inlcuding the update to the jruby package to do this) until FPC rules on whether it's okay for interpreters and languages which are not completely compatible to share modules. FPC will hopefully have quorum tomorrow morning to meet. If not, or if they have issues with the guidelines, perhaps slavek and I can meet to try to figure out ways around the issues. I'll know more after the FPC meeting time tomorrow morning. -Toshio Hi Toshio, sharing Ruby gems between JRuby and rvm is supported by upstream, so why should we disagree with upstream? They know best what they can support. In Ruby world is JRuby used with ruby gems and other projects in Fedora can only benefit from this behaviour. Hey Marcela, sharing of code by language interpreters that are not fully compatible with each other is a big change to how Fedora ships packages. This needs to be considered by FPC to decide if it's okay to do so and if the methods suggested protect user's who are just trying to install working versions of the applications. Personally, I'm leaning towards liking the concept. Agreeing with the idea of a script to multiplex between different interpreters for applications. And thinking that the Provides and Requires proposal is insufficient. But like I say, I don't know what the rest of FPC thinks. So I don't yet know if we'll need to make small alterations to the Provides and Requires proposal or throw it out and figure out a different way to do it (or if the whole concept will be deemed unfit). I'll know more after the meeting. -Toshio pgpgTXBDqr2Ah.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik jrez...@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? 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. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik jrez...@redhat.com wrote: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/JRuby 1.7 = https://fedoraproject.org/wiki/Features/JRuby_1.7 Contingency Plan Reverting to the previous behaviour will always be doable very easily, no harm will be done. Very easily is a judgement, not a description. Please describe what exactly would be reverted. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
- Original Message -
I think the more interesting question is what to do about extensions
(ie. not pure Ruby gems that contain C code). Last time I looked
JRuby was pretty incompatible; in fact for libguestfs we recommend
that people use the *Java* bindings with JRuby ...
Rich.
JRuby and Ruby won't share extensions. Extensions for Ruby will live in
%{_libdir}/gems/ruby, while extensions for JRuby will in %{_datadir}/gems/jruby
(although we decided not to actually ship any JRuby extension Gems for F19 as
we want to take more time to figure out the guidelines specifics around it).
JRuby is pretty incompatible with C extensions. In fact, guys from upstream
told me that they may even completely drop support for C extensions, as its
very hard to maintain and doesn't really bring significant benefits. That's why
we don't want to do it in Fedora.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
--
Regards,
Bohuslav Slavek Kabrda.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
- Original Message - On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik jrez...@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Regards, Bohuslav Slavek Kabrda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
- Original Message - On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik jrez...@redhat.com wrote: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/JRuby 1.7 = https://fedoraproject.org/wiki/Features/JRuby_1.7 Contingency Plan Reverting to the previous behaviour will always be doable very easily, no harm will be done. Very easily is a judgement, not a description. Please describe what exactly would be reverted. All the special behaviour (sharing Gems, rubypick). The new version should hit Fedora either way and in this case it would work exactly the way JRuby has been working up until now. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Regards, Bohuslav Slavek Kabrda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/JRuby 1.7 = https://fedoraproject.org/wiki/Features/JRuby_1.7 * Detailed description: Transition to JRuby 1.7 will consist of 3 basic steps: - Updating packages Most of the packages that JRuby depends on are in Fedora just because of JRuby, so they can be safely updated. Some dependencies are shared with other packages, so they will have to be discussed with their owners (see #Scope). - Integration with Fedora Normally, each Ruby implementations ships with its own copy of RubyGems library. This is wrong because a) it's bundling, b) there is no reason why multiple Ruby implementations wouldn't be able to share one RubyGems library. There used to be some differencies in JRuby's copy of RubyGems, but the JRuby upstream has been very cooperative and managed to get them all merged into upstream RubyGems. The integration will require changing Fedora's operating_system.rb (place for distro-specific defaults for RubyGems). This change will result into all Gems with binary extensions having to be recompiled, as the binary extension placement will change. See [1] for current operating_system.rb look and its changes from F18. 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. - Changes in packaging None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of the box, but packaging of Gems with JRuby extensions is turning out to be very complicated, so the guidelines for it will be postponed to next release (as well as the actual packaging). Users will be still able to install Gems with JRuby extensions, both system-wide (into /usr/local/) and into their home directories. [1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb [2] https://github.com/bkabrda/rubypick As JRuby is setup to share pure ruby gems with ruby, I don't think this can be approved (inlcuding the update to the jruby package to do this) until FPC rules on whether it's okay for interpreters and languages which are not completely compatible to share modules. FPC will hopefully have quorum tomorrow morning to meet. If not, or if they have issues with the guidelines, perhaps slavek and I can meet to try to figure out ways around the issues. I'll know more after the FPC meeting time tomorrow morning. -Toshio pgpEO2lk8b54d.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/JRuby 1.7 = https://fedoraproject.org/wiki/Features/JRuby_1.7 * Detailed description: Transition to JRuby 1.7 will consist of 3 basic steps: - Updating packages Most of the packages that JRuby depends on are in Fedora just because of JRuby, so they can be safely updated. Some dependencies are shared with other packages, so they will have to be discussed with their owners (see #Scope). - Integration with Fedora Normally, each Ruby implementations ships with its own copy of RubyGems library. This is wrong because a) it's bundling, b) there is no reason why multiple Ruby implementations wouldn't be able to share one RubyGems library. There used to be some differencies in JRuby's copy of RubyGems, but the JRuby upstream has been very cooperative and managed to get them all merged into upstream RubyGems. The integration will require changing Fedora's operating_system.rb (place for distro-specific defaults for RubyGems). This change will result into all Gems with binary extensions having to be recompiled, as the binary extension placement will change. See [1] for current operating_system.rb look and its changes from F18. 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. - Changes in packaging None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of the box, but packaging of Gems with JRuby extensions is turning out to be very complicated, so the guidelines for it will be postponed to next release (as well as the actual packaging). Users will be still able to install Gems with JRuby extensions, both system-wide (into /usr/local/) and into their home directories. [1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb [2] https://github.com/bkabrda/rubypick ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/JRuby 1.7 = https://fedoraproject.org/wiki/Features/JRuby_1.7 * Detailed description: Transition to JRuby 1.7 will consist of 3 basic steps: - Updating packages Most of the packages that JRuby depends on are in Fedora just because of JRuby, so they can be safely updated. Some dependencies are shared with other packages, so they will have to be discussed with their owners (see #Scope). - Integration with Fedora Normally, each Ruby implementations ships with its own copy of RubyGems library. This is wrong because a) it's bundling, b) there is no reason why multiple Ruby implementations wouldn't be able to share one RubyGems library. There used to be some differencies in JRuby's copy of RubyGems, but the JRuby upstream has been very cooperative and managed to get them all merged into upstream RubyGems. The integration will require changing Fedora's operating_system.rb (place for distro-specific defaults for RubyGems). This change will result into all Gems with binary extensions having to be recompiled, as the binary extension placement will change. See [1] for current operating_system.rb look and its changes from F18. 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. - Changes in packaging None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of the box, but packaging of Gems with JRuby extensions is turning out to be very complicated, so the guidelines for it will be postponed to next release (as well as the actual packaging). Users will be still able to install Gems with JRuby extensions, both system-wide (into /usr/local/) and into their home directories. FPC should decide whether and how to share modules between multiple interpreters that don't have 100% compatibility with each other before the interpreters start sharing their module packages. -Toshio pgpTGo4903iY_.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
