Hi all, as F19 is slowly approaching, I thought it'd be great to finalize the stuff about JRuby/Ruby integration with Fedora. Here are the changes and additions around JRuby, that I suggest: * Global changes - As already mentioned in [1], change the default operating_system.rb, the current version is at [2]. The question here is, whether to use versioned directories for extensions. In my opinion we should do that, as users installing Gems under /usr/local may want to install them for different version of JRuby (Rubinius in the future). This change will cost us nothing and will make sure that we can utilize this in the future. - Add additional macros to macros.rubygems, see [3] (if the macros names seem confusing, see the section about packaging gems for JRuby below). - Two connected problems: 1) RPM generates auto provides from shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby? -- We've discussed this situation with Vit and we came up with an interesting proposal for solution. There will be a package (probably with just one file) /usr/bin/ruby. This will be a bash script, that will take all given parameters and pass them to the proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There will be a default choice (MRI, I guess) and the switching will be done by passing _jruby_ (possibly also containing version) or _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not found, the script will automatically try /usr/bin/jruby and if that is not present either, it will print out that user needs to install a Ruby runtime. -- This way, the automatically generated requires will point to the package containing /usr/bin/ruby and not the actual ruby package, therefore leaving it up to user which Ruby runtime he wants to install. -- Also, every executable file with this shebang can be run with _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_", the same for gem, irb and anything that has the proper shebang.
* Changes to packaging - Platform independent packages mustn't R: ruby, unless there is a specific reason to do so. - Packages with MRI binary extensions will have to R: and BR: ruby explictly, not just ruby(abi), as that will also be provided by JRuby. - Packages meant only for JRuby will have to R: and BR: jruby explictly (same reason). These will use the %gem_extdir_jruby macro. - Packages with extensions for both Ruby and JRuby (let's consider rubygem-json, example of converted specfile is at [4]): -- MRI extension will probably stay in the core package (rubygem-json). -- There will be a subpackage with -java suffix (because the naming scheme on rubygems.org gives e.g. json-1.7.5-java). The subpackage will contain it's own .gemspec and because all the directory/file names contain the "-java" string, it will use the %gem_*_java macros. -- The -java subpackage will contain the JRuby extension under %gem_extdir_java and it's platform independent part will be a symlink to platform independent part of its MRI counterpart (e.g. /usr/share/gems/gems/json-1.7.5-java -> /usr/share/gems/gems/json-1.7.5). -- The disadvantage of this approach is, that the core package (rubygem-json) will be a dependency of rubygem-json-java, therefore forcing MRI to be installed.
or
-- The rubygem-json-java package could be independent of rubygem-json (e.g. everything same as above, except it will actually contain the platform independent part). This would in fact not require MRI ruby to be installed, but I'm not sure of the consequences of this. -- A big question is, how to handle provides (applies to both cases). RPM cannot say "I'm fine with rubygem-json or rubygem-json-java", so the -json package will probably have to Provides: rubygem(json-java) and users will have to install these manually, if they want to use JRuby.
* Others: - There is also a general problem with Provides/Requires of the interpreters themselves. I think that JRuby should provide both ruby(abi) = 1.9.1 and ruby(abi) = 1.8. I'm however not sure whether to provide e.g. rubygem(io-console), which is required by rubygems package. The problem with this provide is this: 1) user installs JRuby (that provides rubygem(io-console)) and rubygems. 2) user installs MRI, rubygem-io-console doesn't get installed, as the dependency is already satisfied. 3) "gem" command (specifically its part that depends on io-console) run under MRI fails. As I see it, we probably won't get rid of having MRI ruby installed with JRuby, at least not for the near future (but at least the auto-requires of /usr/bin/ruby can be handled, which is a step in the right direction).
I hope I made my points clear, please share your thoughts/comments/critisism. BTW, I'll be updating my testing repo with JRuby as soon as JRuby 1.7.1 are out. When we agree on how the stuff mentioned above should work and have it approved by FESCo/FPC, I'll start pushing JRuby into F19, but that seems to be far away for now...
Thumbs up if you read the whole mail :) Slavek.
Dne 29.11.2012 09:43, Bohuslav Kabrda napsal(a):
Hi all, as F19 is slowly approaching, I thought it'd be great to finalize the stuff about JRuby/Ruby integration with Fedora. Here are the changes and additions around JRuby, that I suggest:
- Global changes
- As already mentioned in [1], change the default operating_system.rb, the current version is at [2]. The question here is, whether to use versioned directories for extensions. In my opinion we should do that, as users installing Gems under /usr/local may want to install them for different version of JRuby (Rubinius in the future). This change will cost us nothing and will make sure that we can utilize this in the future.
We do not support more version of MRI nor JRuby nor we support anything else. The only exception would be if the interpreter support compatibility modes for different Ruby versions => I am against versioning in /usr/local unless explicitly needed.
- Add additional macros to macros.rubygems, see [3] (if the macros names seem confusing, see the section about packaging gems for JRuby below).
The jruby/java suffixes are confusing. We should go only with one of them. I am inclined to -jruby (not sure why -java was chosen by RubyGems or as a platform)
- Two connected problems: 1) RPM generates auto provides from shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
-- We've discussed this situation with Vit and we came up with an interesting proposal for solution. There will be a package (probably with just one file) /usr/bin/ruby. This will be a bash script, that will take all given parameters and pass them to the proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There will be a default choice (MRI, I guess) and the switching will be done by passing _jruby_ (possibly also containing version) or _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not found, the script will automatically try /usr/bin/jruby and if that is not present either, it will print out that user needs to install a Ruby runtime.
Please note that RubyGems are using similar approach already. E.g. you can run `rake _0.8.7_` to execute your rake task using explicitly defined version of Rake. So we would just extend this idea a bit further.
-- This way, the automatically generated requires will point to the package containing /usr/bin/ruby and not the actual ruby package, therefore leaving it up to user which Ruby runtime he wants to install. -- Also, every executable file with this shebang can be run with _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_", the same for gem, irb and anything that has the proper shebang.
I would be interested if anybody know about any possible showstoppers.
- Changes to packaging
- Platform independent packages mustn't R: ruby, unless there is a specific reason to do so.
- Packages with MRI binary extensions will have to R: and BR: ruby explictly, not just ruby(abi), as that will also be provided by JRuby.
- Packages meant only for JRuby will have to R: and BR: jruby explictly (same reason). These will use the %gem_extdir_jruby macro.
- Packages with extensions for both Ruby and JRuby (let's consider rubygem-json, example of converted specfile is at [4]):
-- MRI extension will probably stay in the core package (rubygem-json). -- There will be a subpackage with -java suffix (because the naming scheme on rubygems.org gives e.g. json-1.7.5-java). The subpackage will contain it's own .gemspec and because all the directory/file names contain the "-java" string, it will use the %gem_*_java macros. -- The -java subpackage will contain the JRuby extension under %gem_extdir_java and it's platform independent part will be a symlink to platform independent part of its MRI counterpart (e.g. /usr/share/gems/gems/json-1.7.5-java -> /usr/share/gems/gems/json-1.7.5). -- The disadvantage of this approach is, that the core package (rubygem-json) will be a dependency of rubygem-json-java, therefore forcing MRI to be installed.
or
-- The rubygem-json-java package could be independent of rubygem-json (e.g. everything same as above, except it will actually contain the platform independent part). This would in fact not require MRI ruby to be installed, but I'm not sure of the consequences of this. -- A big question is, how to handle provides (applies to both cases). RPM cannot say "I'm fine with rubygem-json or rubygem-json-java", so the -json package will probably have to Provides: rubygem(json-java) and users will have to install these manually, if they want to use JRuby.
Taking rubygem-json as an example, I'd love to see:
rubygem-json - contains platform independent code rubygem-json-mri - subpackage containing MRI binary extension rubygem-json-jruby - subpackage containing JRuby extension
Unfortunately, there is probably no way how to install proper subpackages, unless we would go with comps [1] for example. But I opened ticket on RPM [2] requesting support for this.
Vít
[1] http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_grou... [2] http://rpm.org/ticket/857
----- Original Message -----
Dne 29.11.2012 09:43, Bohuslav Kabrda napsal(a):
Hi all, as F19 is slowly approaching, I thought it'd be great to finalize the stuff about JRuby/Ruby integration with Fedora. Here are the changes and additions around JRuby, that I suggest:
- Global changes
- As already mentioned in [1], change the default
operating_system.rb, the current version is at [2]. The question here is, whether to use versioned directories for extensions. In my opinion we should do that, as users installing Gems under /usr/local may want to install them for different version of JRuby (Rubinius in the future). This change will cost us nothing and will make sure that we can utilize this in the future.
We do not support more version of MRI nor JRuby nor we support anything else. The only exception would be if the interpreter support compatibility modes for different Ruby versions => I am against versioning in /usr/local unless explicitly needed.
I meant the interpreters that support multiple compatible modes. So e.g. Rubinius users may want to install extensions under /usr/local for both ruby-1.8 and ruby-1.9 compat modes (once we have Rubinius). It is true, that for now this shouldn't be needed (as Charles has mentioned, JRuby extensions should work with both compat modes). I do not consider this to be a "must have" feature, so if you'll shout at me for a long enough time, I'll just give it up ;)
- Add additional macros to macros.rubygems, see [3] (if the macros
names seem confusing, see the section about packaging gems for JRuby below).
The jruby/java suffixes are confusing. We should go only with one of them. I am inclined to -jruby (not sure why -java was chosen by RubyGems or as a platform)
Yep, I agree that they may seem confusing. We may use "_jruby" (I'm assuming that you're talking about the macro names, not the actual directories/gemspecs/etc), but we have to find a good way of distinguishing between the extdir that contains "-java" suffix and extdir that doesn't contain it (for JRuby-only gems). So how about 1) All the JRuby macros have "_jruby" suffix. 2) The ext dir for JRuby gems that don't contain "-java" in their name, the macro would be called sth. like %{gem_extdir_jruby_pure}.
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby? -- We've discussed this situation with Vit and we came up with an interesting proposal for solution. There will be a package (probably with just one file) /usr/bin/ruby. This will be a bash script, that will take all given parameters and pass them to the proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There will be a default choice (MRI, I guess) and the switching will be done by passing _jruby_ (possibly also containing version) or _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not found, the script will automatically try /usr/bin/jruby and if that is not present either, it will print out that user needs to install a Ruby runtime.
Please note that RubyGems are using similar approach already. E.g. you can run `rake _0.8.7_` to execute your rake task using explicitly defined version of Rake. So we would just extend this idea a bit further.
-- This way, the automatically generated requires will point to the package containing /usr/bin/ruby and not the actual ruby package, therefore leaving it up to user which Ruby runtime he wants to install. -- Also, every executable file with this shebang can be run with _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_", the same for gem, irb and anything that has the proper shebang.
I would be interested if anybody know about any possible showstoppers.
- Changes to packaging
- Platform independent packages mustn't R: ruby, unless there is a
specific reason to do so.
- Packages with MRI binary extensions will have to R: and BR: ruby
explictly, not just ruby(abi), as that will also be provided by JRuby.
- Packages meant only for JRuby will have to R: and BR: jruby
explictly (same reason). These will use the %gem_extdir_jruby macro.
- Packages with extensions for both Ruby and JRuby (let's consider
rubygem-json, example of converted specfile is at [4]): -- MRI extension will probably stay in the core package (rubygem-json). -- There will be a subpackage with -java suffix (because the naming scheme on rubygems.org gives e.g. json-1.7.5-java). The subpackage will contain it's own .gemspec and because all the directory/file names contain the "-java" string, it will use the %gem_*_java macros. -- The -java subpackage will contain the JRuby extension under %gem_extdir_java and it's platform independent part will be a symlink to platform independent part of its MRI counterpart (e.g. /usr/share/gems/gems/json-1.7.5-java -> /usr/share/gems/gems/json-1.7.5). -- The disadvantage of this approach is, that the core package (rubygem-json) will be a dependency of rubygem-json-java, therefore forcing MRI to be installed.
or
-- The rubygem-json-java package could be independent of rubygem-json (e.g. everything same as above, except it will actually contain the platform independent part). This would in fact not require MRI ruby to be installed, but I'm not sure of the consequences of this. -- A big question is, how to handle provides (applies to both cases). RPM cannot say "I'm fine with rubygem-json or rubygem-json-java", so the -json package will probably have to Provides: rubygem(json-java) and users will have to install these manually, if they want to use JRuby.
Taking rubygem-json as an example, I'd love to see:
rubygem-json - contains platform independent code rubygem-json-mri - subpackage containing MRI binary extension rubygem-json-jruby - subpackage containing JRuby extension
Unfortunately, there is probably no way how to install proper subpackages, unless we would go with comps [1] for example. But I opened ticket on RPM [2] requesting support for this.
Yep, that would be exactly what we need and we should really push for this. But I don't see this solution coming for F19, so we will have to make a temporary decision for the time being. Thinking of the two above alternatives further, I would prefer the first one, because the Requires: rubygem(json) will pull rubygem-json in anyway, so the second solution doesn't in fact bring benefits in terms of RPM dependencies.
Vít
[1] http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_grou... [2] http://rpm.org/ticket/857
Thanks for your thoughts, Vit. I hope the others will comment as well :)
On 12/03/2012 02:54 AM, Bohuslav Kabrda wrote:
----- Original Message -----
Dne 29.11.2012 09:43, Bohuslav Kabrda napsal(a):
Hi all, as F19 is slowly approaching, I thought it'd be great to finalize the stuff about JRuby/Ruby integration with Fedora. Here are the changes and additions around JRuby, that I suggest:
- Global changes
- As already mentioned in [1], change the default
operating_system.rb, the current version is at [2]. The question here is, whether to use versioned directories for extensions. In my opinion we should do that, as users installing Gems under /usr/local may want to install them for different version of JRuby (Rubinius in the future). This change will cost us nothing and will make sure that we can utilize this in the future.
We do not support more version of MRI nor JRuby nor we support anything else. The only exception would be if the interpreter support compatibility modes for different Ruby versions => I am against versioning in /usr/local unless explicitly needed.
I meant the interpreters that support multiple compatible modes. So e.g. Rubinius users may want to install extensions under /usr/local for both ruby-1.8 and ruby-1.9 compat modes (once we have Rubinius). It is true, that for now this shouldn't be needed (as Charles has mentioned, JRuby extensions should work with both compat modes). I do not consider this to be a "must have" feature, so if you'll shout at me for a long enough time, I'll just give it up ;)
Ya you both have good points. Feel Bohuslav's proposal would cover more edge cases but Vit's makes a good argument for simplicity. Suppose I'm leaning more towards being able to handle the multiple compatibility modes (but then again I'm not the one implementing it!)
- Add additional macros to macros.rubygems, see [3] (if the macros
names seem confusing, see the section about packaging gems for JRuby below).
The jruby/java suffixes are confusing. We should go only with one of them. I am inclined to -jruby (not sure why -java was chosen by RubyGems or as a platform)
Yep, I agree that they may seem confusing. We may use "_jruby" (I'm assuming that you're talking about the macro names, not the actual directories/gemspecs/etc), but we have to find a good way of distinguishing between the extdir that contains "-java" suffix and extdir that doesn't contain it (for JRuby-only gems). So how about
- All the JRuby macros have "_jruby" suffix.
- The ext dir for JRuby gems that don't contain "-java" in their name, the macro would be called sth. like %{gem_extdir_jruby_pure}.
+1 to -jruby over -java
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby? -- We've discussed this situation with Vit and we came up with an interesting proposal for solution. There will be a package (probably with just one file) /usr/bin/ruby. This will be a bash script, that will take all given parameters and pass them to the proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There will be a default choice (MRI, I guess) and the switching will be done by passing _jruby_ (possibly also containing version) or _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not found, the script will automatically try /usr/bin/jruby and if that is not present either, it will print out that user needs to install a Ruby runtime.
Please note that RubyGems are using similar approach already. E.g. you can run `rake _0.8.7_` to execute your rake task using explicitly defined version of Rake. So we would just extend this idea a bit further.
-- This way, the automatically generated requires will point to the package containing /usr/bin/ruby and not the actual ruby package, therefore leaving it up to user which Ruby runtime he wants to install. -- Also, every executable file with this shebang can be run with _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_", the same for gem, irb and anything that has the proper shebang.
I would be interested if anybody know about any possible showstoppers.
Ya this is very interesting. My only concern that somehow we'd break upstream tools and such, but I can't think of any specific ways so maybe I'm just being paranoid.
Of course the script would need to pass all additional command line flags to the interpreter and as you mentioned, if the first parameter is not detected to be 'mri' or 'jruby' we should have a default
Doesn't matter to me which one is the default, would people be interested to trying jruby as the default of Fedora 19? Or perhaps we should push that change off till the next Fedora release when all this will have stabilized a bit.
- Changes to packaging
- Platform independent packages mustn't R: ruby, unless there is a
specific reason to do so.
- Packages with MRI binary extensions will have to R: and BR: ruby
explictly, not just ruby(abi), as that will also be provided by JRuby.
- Packages meant only for JRuby will have to R: and BR: jruby
explictly (same reason). These will use the %gem_extdir_jruby macro.
- Packages with extensions for both Ruby and JRuby (let's consider
rubygem-json, example of converted specfile is at [4]): -- MRI extension will probably stay in the core package (rubygem-json). -- There will be a subpackage with -java suffix (because the naming scheme on rubygems.org gives e.g. json-1.7.5-java). The subpackage will contain it's own .gemspec and because all the directory/file names contain the "-java" string, it will use the %gem_*_java macros. -- The -java subpackage will contain the JRuby extension under %gem_extdir_java and it's platform independent part will be a symlink to platform independent part of its MRI counterpart (e.g. /usr/share/gems/gems/json-1.7.5-java -> /usr/share/gems/gems/json-1.7.5). -- The disadvantage of this approach is, that the core package (rubygem-json) will be a dependency of rubygem-json-java, therefore forcing MRI to be installed.
or
-- The rubygem-json-java package could be independent of rubygem-json (e.g. everything same as above, except it will actually contain the platform independent part). This would in fact not require MRI ruby to be installed, but I'm not sure of the consequences of this. -- A big question is, how to handle provides (applies to both cases). RPM cannot say "I'm fine with rubygem-json or rubygem-json-java", so the -json package will probably have to Provides: rubygem(json-java) and users will have to install these manually, if they want to use JRuby.
Taking rubygem-json as an example, I'd love to see:
rubygem-json - contains platform independent code rubygem-json-mri - subpackage containing MRI binary extension rubygem-json-jruby - subpackage containing JRuby extension
Unfortunately, there is probably no way how to install proper subpackages, unless we would go with comps [1] for example. But I opened ticket on RPM [2] requesting support for this.
Yep, that would be exactly what we need and we should really push for this. But I don't see this solution coming for F19, so we will have to make a temporary decision for the time being. Thinking of the two above alternatives further, I would prefer the first one, because the Requires: rubygem(json) will pull rubygem-json in anyway, so the second solution doesn't in fact bring benefits in terms of RPM dependencies.
Ya also +1 to the first, seems like more naturally aligned w/ the current setup and tooling.
Also dislike the dependency on MRI for the jruby stuff, would be awesome to be able to get that feature into RPM.
Vít
[1] http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_grou... [2] http://rpm.org/ticket/857
Thanks for your thoughts, Vit. I hope the others will comment as well :)
Thanks to both of you for all of this, exciting times for Ruby on Fedora :-)
-Mo
----- Original Message -----
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby? -- We've discussed this situation with Vit and we came up with an interesting proposal for solution. There will be a package (probably with just one file) /usr/bin/ruby. This will be a bash script, that will take all given parameters and pass them to the proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There will be a default choice (MRI, I guess) and the switching will be done by passing _jruby_ (possibly also containing version) or _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not found, the script will automatically try /usr/bin/jruby and if that is not present either, it will print out that user needs to install a Ruby runtime.
Please note that RubyGems are using similar approach already. E.g. you can run `rake _0.8.7_` to execute your rake task using explicitly defined version of Rake. So we would just extend this idea a bit further.
-- This way, the automatically generated requires will point to the package containing /usr/bin/ruby and not the actual ruby package, therefore leaving it up to user which Ruby runtime he wants to install. -- Also, every executable file with this shebang can be run with _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_", the same for gem, irb and anything that has the proper shebang.
I would be interested if anybody know about any possible showstoppers.
Ya this is very interesting. My only concern that somehow we'd break upstream tools and such, but I can't think of any specific ways so maybe I'm just being paranoid.
Of course the script would need to pass all additional command line flags to the interpreter and as you mentioned, if the first parameter is not detected to be 'mri' or 'jruby' we should have a default
Doesn't matter to me which one is the default, would people be interested to trying jruby as the default of Fedora 19? Or perhaps we should push that change off till the next Fedora release when all this will have stabilized a bit.
I have just pushed all of this stuff into my testing repo [1] (the /usr/bin/ruby stub, modified MRI Ruby, etc.), so you can test that now. For me, it seems to work. I call the stub "multiruby" (actually Vit's idea :) ) and its upstream is at [2] (no fancy git tags and stuff, I just made it work for now...). By default, the stub uses MRI. It seems to work ok, I have also tried benchmarking the execution time and the stub is 1 second slower in 1000 executions. That means 133 vs. 132 secs - that's 0.7 % slower, I think we can live with that :) Please note that when working with my testing repo, you should only install to mock chroot, otherwise it can do bad things to your current Ruby installation. Also, the json gem may seem broken (cannot load extensions), but that is because F 19 places extensions in different directory and its version is newer than version in my repo. So if you want to workaround that, either install rubygem-json_pure into the chroot or "gem install json" in the chroot (this will place the extensions according to new layout).
- Changes to packaging
- Platform independent packages mustn't R: ruby, unless there is
a specific reason to do so.
- Packages with MRI binary extensions will have to R: and BR:
ruby explictly, not just ruby(abi), as that will also be provided by JRuby.
- Packages meant only for JRuby will have to R: and BR: jruby
explictly (same reason). These will use the %gem_extdir_jruby macro.
- Packages with extensions for both Ruby and JRuby (let's
consider rubygem-json, example of converted specfile is at [4]): -- MRI extension will probably stay in the core package (rubygem-json). -- There will be a subpackage with -java suffix (because the naming scheme on rubygems.org gives e.g. json-1.7.5-java). The subpackage will contain it's own .gemspec and because all the directory/file names contain the "-java" string, it will use the %gem_*_java macros. -- The -java subpackage will contain the JRuby extension under %gem_extdir_java and it's platform independent part will be a symlink to platform independent part of its MRI counterpart (e.g. /usr/share/gems/gems/json-1.7.5-java -> /usr/share/gems/gems/json-1.7.5). -- The disadvantage of this approach is, that the core package (rubygem-json) will be a dependency of rubygem-json-java, therefore forcing MRI to be installed.
or
-- The rubygem-json-java package could be independent of rubygem-json (e.g. everything same as above, except it will actually contain the platform independent part). This would in fact not require MRI ruby to be installed, but I'm not sure of the consequences of this. -- A big question is, how to handle provides (applies to both cases). RPM cannot say "I'm fine with rubygem-json or rubygem-json-java", so the -json package will probably have to Provides: rubygem(json-java) and users will have to install these manually, if they want to use JRuby.
Taking rubygem-json as an example, I'd love to see:
rubygem-json - contains platform independent code rubygem-json-mri - subpackage containing MRI binary extension rubygem-json-jruby - subpackage containing JRuby extension
Unfortunately, there is probably no way how to install proper subpackages, unless we would go with comps [1] for example. But I opened ticket on RPM [2] requesting support for this.
Yep, that would be exactly what we need and we should really push for this. But I don't see this solution coming for F19, so we will have to make a temporary decision for the time being. Thinking of the two above alternatives further, I would prefer the first one, because the Requires: rubygem(json) will pull rubygem-json in anyway, so the second solution doesn't in fact bring benefits in terms of RPM dependencies.
Ya also +1 to the first, seems like more naturally aligned w/ the current setup and tooling.
Also dislike the dependency on MRI for the jruby stuff, would be awesome to be able to get that feature into RPM.
Yes, I'm also +1 for the first one, I was just presenting possibilities. Vit's proposed solution would be the best one, but it's currently not doable. I'm afraid that we won't get rid of installing MRI with JRuby for now, but I guess it's better than nothing :)
Vít
[1] http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_grou... [2] http://rpm.org/ticket/857
Thanks for your thoughts, Vit. I hope the others will comment as well :)
Thanks to both of you for all of this, exciting times for Ruby on Fedora :-)
-Mo
Dne 4.12.2012 15:54, Bohuslav Kabrda napsal(a):
I call the stub "multiruby" (actually Vit's idea :) )
Well, if you have better idea how to name it, please speak out now :)
Considering that this method is similar to Alternatives [1] and Environment modules [2], may be we should find some better name for this general approach.
Vit
[1] http://fedoraproject.org/wiki/Packaging:Alternatives [2] http://fedoraproject.org/wiki/Packaging:EnvironmentModules
Dne 4.12.2012 15:54, Bohuslav Kabrda napsal(a):
I have just pushed all of this stuff into my testing repo [1] (the /usr/bin/ruby stub, modified MRI Ruby, etc.), so you can test that now. For me, it seems to work. I call the stub "multiruby" (actually Vit's idea :) ) and its upstream is at [2] (no fancy git tags and stuff, I just made it work for now...). By default, the stub uses MRI.
I should also point out that you can try to use different rubies such as:
$ ruby _mri_ -v $ ruby _jruby_ -v
Slavek, any indea if we could provide some help? Something like "ruby _help_" for example? However I am not sure if anybody is able to find this command :/
Vít
----- Original Message -----
Dne 4.12.2012 15:54, Bohuslav Kabrda napsal(a):
I have just pushed all of this stuff into my testing repo [1] (the /usr/bin/ruby stub, modified MRI Ruby, etc.), so you can test that now. For me, it seems to work. I call the stub "multiruby" (actually Vit's idea :) ) and its upstream is at [2] (no fancy git tags and stuff, I just made it work for now...). By default, the stub uses MRI.
I should also point out that you can try to use different rubies such as:
$ ruby _mri_ -v $ ruby _jruby_ -v
Slavek, any indea if we could provide some help? Something like "ruby _help_" for example? However I am not sure if anybody is able to find this command :/
Vít
I think I could add a hook for -h, that would first print help for the multiruby script and then keep running for the used interpreter. So something like $ ruby -h This is Fedora's multiruby executable. You can blah blah blah... Currently available runtimes: _mri_ (default), _jruby_
Selected: _mri_
<actual help for MRI>
I think this shouldn't affect the performance and it shouldn't damage user experience. Does that sound sane?
On 12/04, Vít Ondruch wrote:
Dne 4.12.2012 15:54, Bohuslav Kabrda napsal(a):
I have just pushed all of this stuff into my testing repo [1] (the /usr/bin/ruby stub, modified MRI Ruby, etc.), so you can test that now. For me, it seems to work. I call the stub "multiruby" (actually Vit's idea :) ) and its upstream is at [2] (no fancy git tags and stuff, I just made it work for now...). By default, the stub uses MRI.
I should also point out that you can try to use different rubies such as:
$ ruby _mri_ -v $ ruby _jruby_ -v
How about:
$ RUBY_PLATFORM=mri ruby -v $ RUBY_PLATFORM=jruby ruby -v
In this case you're not introducing cross-platform incompatibility for shebangs ;-)
-- Michal
Slavek, any indea if we could provide some help? Something like "ruby _help_" for example? However I am not sure if anybody is able to find this command :/
Vít _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 13.12.2012 15:56, Michal Fojtik napsal(a):
On 12/04, Vít Ondruch wrote:
I should also point out that you can try to use different rubies such as:
$ ruby _mri_ -v $ ruby _jruby_ -v
How about:
$ RUBY_PLATFORM=mri ruby -v $ RUBY_PLATFORM=jruby ruby -v
I would consider it as alternative. Who likes so much typing? And if you are alarmist, you should be afraid of possible env variable collision :)
In this case you're not introducing cross-platform incompatibility for shebangs ;-)
I am not afraid of shebangs incompatibility. I hope that if there will be JRuby specific code, nobody will come with #!/usr/bin/ruby _jruby_ shebang, but will go with !#/usr/bin/jruby. Not sure why s/he would use such shebang anyway.
Vít
On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
- Two connected problems: 1) RPM generates auto provides from shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
We already have mechanism for that:
/etc/alternatives/* update-alternatives(8)
/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as /usr/bin/ruby). And let update-alternatives manage the defaults.
Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
We already have mechanism for that:
/etc/alternatives/* update-alternatives(8)
/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as /usr/bin/ruby). And let update-alternatives manage the defaults.
Yes, we have, but you need to have root privileges to use them. That is not cool. We believe that something like this script [1] could make better service.
Vít
On 12/13, Vít Ondruch wrote:
Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
We already have mechanism for that:
/etc/alternatives/* update-alternatives(8)
/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as /usr/bin/ruby). And let update-alternatives manage the defaults.
Maybe a stupid idea, but why we just don't prefix the 'jruby' with 'j'?
So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem... (jirb, jgem, etc...)
Then the shebang will be '#!/usr/bin/jruby' and the MRI version can cooexist with the jruby.
-- michal
Yes, we have, but you need to have root privileges to use them. That is not cool. We believe that something like this script [1] could make better service.
Vít
[1] https://github.com/bkabrda/multiruby/blob/master/ruby _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
BTW, is it not the default behavior? There should be no jruby executable in the official distro.
-- mj
On Dec 13, 2012, at 10:02 AM, Michal Fojtik wrote:
On 12/13, Vít Ondruch wrote:
Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
We already have mechanism for that:
/etc/alternatives/* update-alternatives(8)
/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as /usr/bin/ruby). And let update-alternatives manage the defaults.
Maybe a stupid idea, but why we just don't prefix the 'jruby' with 'j'?
So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem... (jirb, jgem, etc...)
Then the shebang will be '#!/usr/bin/jruby' and the MRI version can cooexist with the jruby.
-- michal
Yes, we have, but you need to have root privileges to use them. That is not cool. We believe that something like this script [1] could make better service.
Vít
[1] https://github.com/bkabrda/multiruby/blob/master/ruby _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
-- Michal Fojtik mfojtik@redhat.com Deltacloud API, CloudForms _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 13.12.2012 10:02, Michal Fojtik napsal(a):
On 12/13, Vít Ondruch wrote:
Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
We already have mechanism for that:
/etc/alternatives/* update-alternatives(8)
/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as /usr/bin/ruby). And let update-alternatives manage the defaults.
Maybe a stupid idea, but why we just don't prefix the 'jruby' with 'j'?
So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem... (jirb, jgem, etc...)
Then the shebang will be '#!/usr/bin/jruby' and the MRI version can cooexist with the jruby.
-- michal
There is probably million of ruby scripts which has some #!ruby shebang. If only JRuby is on the system, they'll continue to work. Typical user does not care if he runs something by MRI, JRuby or Rubinius. S/he only cares if it works.
Actually, I am speaking about typical user, but I personally don't care. I don't care if I run gem2rpm by MRI or JRuby, if it works.
Vít
Dne 13.12.2012 11:50, Vít Ondruch napsal(a):
Dne 13.12.2012 10:02, Michal Fojtik napsal(a):
On 12/13, Vít Ondruch wrote:
Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
We already have mechanism for that:
/etc/alternatives/* update-alternatives(8)
/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as /usr/bin/ruby). And let update-alternatives manage the defaults.
Maybe a stupid idea, but why we just don't prefix the 'jruby' with 'j'?
So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem... (jirb, jgem, etc...)
Then the shebang will be '#!/usr/bin/jruby' and the MRI version can cooexist with the jruby.
-- michal
There is probably million of ruby scripts which has some #!ruby shebang. If only JRuby is on the system, they'll continue to work.
* Of course "they'll not work" I meant
Typical user does not care if he runs something by MRI, JRuby or Rubinius. S/he only cares if it works.
Actually, I am speaking about typical user, but I personally don't care. I don't care if I run gem2rpm by MRI or JRuby, if it works.
Vít
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 12/13, Vít Ondruch wrote:
Dne 13.12.2012 10:02, Michal Fojtik napsal(a):
On 12/13, Vít Ondruch wrote:
Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
We already have mechanism for that:
/etc/alternatives/* update-alternatives(8)
/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as /usr/bin/ruby). And let update-alternatives manage the defaults.
Maybe a stupid idea, but why we just don't prefix the 'jruby' with 'j'?
So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem... (jirb, jgem, etc...)
Then the shebang will be '#!/usr/bin/jruby' and the MRI version can cooexist with the jruby.
-- michal
There is probably million of ruby scripts which has some #!ruby shebang. If only JRuby is on the system, they'll continue to work.
Why you assume that this 'milion' of ruby scripts with MRI shebangs will continue to work on jRuby (if only that ruby is installed in system)?
Typical user does not care if he runs something by MRI, JRuby or Rubinius. S/he only cares if it works.
Well 'typical' user here is someone that wants to run his things on jRuby in **production**, but develop using MRI (there are milion reasons why),
A typical user will never use Fedora MRI for development but will install something like RVM or rbenv. Again, milion reasons why.
My point was to make it clear when I run something on my MRI ruby (development/scripts) and when I run something on jRuby (production).
Btw. are there some personas or something for Ruby users in Fedora? Like:
Bob, the system administrator that wants to have Puppet running. Dave, web developer that wants to deploy apps on Fedora/RHEL
etc..
Having something like that will maybe help in future :-)
Actually, I am speaking about typical user, but I personally don't care. I don't care if I run gem2rpm by MRI or JRuby, if it works.
You will probably find out in a while, that using 'scripts' on jRuby isn't the best thing you do ;-) (like JVM boot time, etc).
-- Michal
Dne 13.12.2012 13:15, Michal Fojtik napsal(a):
On 12/13, Vít Ondruch wrote:
Dne 13.12.2012 10:02, Michal Fojtik napsal(a):
On 12/13, Vít Ondruch wrote:
Dne 12.12.2012 18:36, Miroslav Suchý napsal(a):
On 11/29/2012 09:43 AM, Bohuslav Kabrda wrote:
- Two connected problems: 1) RPM generates auto provides from
shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
We already have mechanism for that:
/etc/alternatives/* update-alternatives(8)
/usr/bin/ruby will be symlink to /etc/alternatives/ruby, which will be symlink to /usr/bin/jruby or /usr/bin/ruby19 (previously known as /usr/bin/ruby). And let update-alternatives manage the defaults.
Maybe a stupid idea, but why we just don't prefix the 'jruby' with 'j'?
So we can have lancher in '/usr/bin/jruby'. Similar for irb, gem... (jirb, jgem, etc...)
Then the shebang will be '#!/usr/bin/jruby' and the MRI version can cooexist with the jruby.
-- michal
There is probably million of ruby scripts which has some #!ruby shebang. If only JRuby is on the system, they'll continue to work.
Why you assume that this 'milion' of ruby scripts with MRI shebangs will continue to work on jRuby (if only that ruby is installed in system)?
Shouldn't they? They are just Ruby. There might be definitely JRuby specific scripts or MRI specific scripts, but in 99% it is just bug IMO.
Typical user does not care if he runs something by MRI, JRuby or Rubinius. S/he only cares if it works.
Well 'typical' user here is someone that wants to run his things on jRuby in **production**, but develop using MRI (there are milion reasons why),
Typical user install software using RPM, this is first premise. They have no custom scripts, no additional gems, etc.
A typical user will never use Fedora MRI for development but will install something like RVM or rbenv. Again, milion reasons why.
Typical user will not develop.
My point was to make it clear when I run something on my MRI ruby (development/scripts) and when I run something on jRuby (production).
There will be available jruby and ruby-mri (have not thought about the name yet) executables if you want to be sure.
Btw. are there some personas or something for Ruby users in Fedora? Like:
Bob, the system administrator that wants to have Puppet running. Dave, web developer that wants to deploy apps on Fedora/RHEL
etc..
Having something like that will maybe help in future :-)
Oh please :)
Actually, I am speaking about typical user, but I personally don't care. I don't care if I run gem2rpm by MRI or JRuby, if it works.
You will probably find out in a while, that using 'scripts' on jRuby isn't the best thing you do ;-) (like JVM boot time, etc).
That is true, but if you have at lease some ruby on your system, it is better to execute script slowly, then not execute at all.
-- Michal
On 12/13/2012 08:31 AM, Vít Ondruch wrote:
Yes, we have, but you need to have root privileges to use them. That is not cool.
Why is not cool? If everything with #!ruby should be executed by jruby instead of cRuby, then I would expect that I need root privileges for this change.
Dne 8.1.2013 11:46, Miroslav Suchý napsal(a):
On 12/13/2012 08:31 AM, Vít Ondruch wrote:
Yes, we have, but you need to have root privileges to use them. That is not cool.
Why is not cool? If everything with #!ruby should be executed by jruby instead of cRuby, then I would expect that I need root privileges for this change.
Yes, "if everything" and if system administrator should decide about it. E.g.
1) System administrator decides that he wants JRuby and JRuby only on the system, them he installs just JRuby and everything works. User cannot choose. 2) System administrator decides that hew wants to have available MRI, JRuby and Rubinius on the system and user can freely choose, then alternatives cannot help.
Vít
ruby-sig@lists.fedoraproject.org
-
Bohuslav Kabrda -
Marek Jelen -
Michal Fojtik -
Miroslav Suchý -
Mo Morsi -
Vít Ondruch