The next release of JRuby (0.9.0) is the first release in which RubyGems works and gems install correctly from local and remote locations. It will also be the first release in which we ship a full complement of Ruby's own .rb libraries. In short, it's the first really usable release with everything you need included. However, we have a conundrum with RubyGems.
We would like to ship the release archive with RubyGems pre-installed. The installation is no big deal, and we'll just run it before wrapping things up and shipping it. However, because we look like a *NIX platform RubyGems installs just the standard unixy #! scripts. That means with a stock JRuby, Windows users would be out of luck. To make matters worse, our startup command is always "jruby" and those scripts assume the startup command is always "ruby". Therefore, we can't just invoke the scripts directly. We obviously want a way to make them run with JRuby instead of Ruby, but we don't want to break existing Ruby installs in the process. A few suggestions have been forwarded:
- Rename jruby startup scripts to 'ruby' (Obviously bad because it would mask a pre-existing Ruby install, so not high on our list) - Modify the installed gem scripts to invoke jruby instead of ruby (Not a bad suggestion, but it would only take a single gemupdate to wipe out our custom scripts) - Provide "J"-prefixed versions of the RubyGems scripts that know how to invoke thins correctly, e.g. jgem, jgemupdate (Ugly, but the most clean and compatible solution by far; the RubyGems scripts could then update without breaking anything, and the J-prefixed versions would always work. However, it creates a bunch of new scripts to maintain, and did I mention it's a little ugly?) - Unixers can symlink ruby to jruby's startup script (Same down side as the first bullet, but at least the user is explicitly accepting that)
Are there any other suggestions, or comments on these? If you were to use JRuby with RubyGems pre-installed, how would you want it to work? How would you NOT want it to work?
-- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com
On 6/12/06, Charles O Nutter <head...@headius.com> wrote:
> - Rename jruby startup scripts to 'ruby' > (Obviously bad because it would mask a pre-existing Ruby install, so not > high on our list) > - Modify the installed gem scripts to invoke jruby instead of ruby > (Not a bad suggestion, but it would only take a single gemupdate to wipe out > our custom scripts) > - Provide "J"-prefixed versions of the RubyGems scripts that know how to > invoke thins correctly, e.g. jgem, jgemupdate > (Ugly, but the most clean and compatible solution by far; the RubyGems > scripts could then update without breaking anything, and the J-prefixed > versions would always work. However, it creates a bunch of new scripts to > maintain, and did I mention it's a little ugly?)
I think this is the best option. You could probably work with RubyGems to get them to use something like Config::CONFIG["RUBY_INSTALL_NAME"]. It would also be useful if they created the .cmd scripts based on something other than just platform. ;)
If we were to talk about "fixing" the installation of RubyGems, I think the following might be a good model:
- base the files installed off querying something from the implementation (like whether to install unix or windows-friendly scripts...or both in our case) - modify the scripts to reference the install platform's ruby executables (jruby (sh) or jruby.bat in our case)
That would certainly be ideal for a future rubygems release; if we were able to count on the installer asking us how it should install itself, we'd avoid all issues with script naming and updating.
On 6/13/06, Austin Ziegler <halosta...@gmail.com> wrote:
> On 6/12/06, Charles O Nutter <head...@headius.com> wrote: > > - Rename jruby startup scripts to 'ruby' > > (Obviously bad because it would mask a pre-existing Ruby install, so not > > high on our list) > > - Modify the installed gem scripts to invoke jruby instead of ruby > > (Not a bad suggestion, but it would only take a single gemupdate to wipe > out > > our custom scripts) > > - Provide "J"-prefixed versions of the RubyGems scripts that know how to > > invoke thins correctly, e.g. jgem, jgemupdate > > (Ugly, but the most clean and compatible solution by far; the RubyGems > > scripts could then update without breaking anything, and the J-prefixed > > versions would always work. However, it creates a bunch of new scripts > to > > maintain, and did I mention it's a little ugly?)
> I think this is the best option. You could probably work with RubyGems > to get them to use something like Config::CONFIG["RUBY_INSTALL_NAME"]. > It would also be useful if they created the .cmd scripts based on > something other than just platform. ;)
Charles O Nutter wrote: > [...] However, because we look like a *NIX platform RubyGems > installs just the standard unixy #! scripts. That means with a stock > JRuby, > Windows users would be out of luck.
What does your Config::CONFIG['arch'] look like?
> To make matters worse, our startup > command is always "jruby" and those scripts assume the startup command > is > always "ruby".
On 6/13/06, Jim Weirich <j...@weirichhouse.org> wrote:
> What does your Config::CONFIG['arch'] look like?
Actually it appears to be nil right now; I will fix that based on this discussion. When corrected it will likely be 'java', perhaps with a real underlying platform (win32, linux, whatever) as well. I think it's probably important that java be mentioned, given that we're a distinctly different platform, underlying operating system notwithstanding. ...time passes... I've made it 'java' for the moment. If we can settle this before our 0.9.0release in the next couple days, I'll change it to whatever.
> What are the bindir and ruby_install_name values set to under JRuby?
bindir = <jruby_home>/bin, so it's pointing at the correct location for... ruby_install_name = 'jruby.bat' on my Windows machine, likely just 'jruby' on *nix.
The RubyGems teams is very willing to work this out.
Thank you much! We're also willing to tailor the Config items most interesting to RubyGems to better suit how they're being used. Given the above, I'd see the following scenario:
The "ruby" executable on a windows machine would be <jruby_home>/bin/jruby.bat. The arch could be something like 'java' or maybe 'java-win32'. I'm inclined to make it as OS-agnostic as possible, but the legend of complete platform independence is long and storied. If we need the -platform bit, it's probably doable. Preference would be to exclude. RubyGems scripts would be installed such that they use jruby.bat instead of 'ruby'. If arch == 'java', I'd say it would be best to install both Windows and *nix scripts, so they're all present. If arch provides more platform information like 'win32', RubyGems could choose appropriately.
-- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com
FYI, if platform was needed, we could most easily provide "java-windows", "java-x86", or "java-windows-x86" (or some combination) given what the JVM tells us (System properties os.arch = x86 and os.name = windows). Anything beyond that would require massaging "windows" and "x86" into something else.
On 6/14/06, Charles O Nutter <head...@headius.com> wrote:
> On 6/13/06, Jim Weirich <j...@weirichhouse.org> wrote:
> > What does your Config::CONFIG['arch'] look like?
> Actually it appears to be nil right now; I will fix that based on this > discussion. When corrected it will likely be 'java', perhaps with a real > underlying platform (win32, linux, whatever) as well. I think it's probably > important that java be mentioned, given that we're a distinctly different > platform, underlying operating system notwithstanding. > ...time passes... > I've made it 'java' for the moment. If we can settle this before our 0.9.0release in the next couple days, I'll change it to whatever.
> > What are the bindir and ruby_install_name values set to under JRuby?
> bindir = <jruby_home>/bin, so it's pointing at the correct location for...
> ruby_install_name = 'jruby.bat' on my Windows machine, likely just 'jruby' > on *nix.
> The RubyGems teams is very willing to work this out.
> Thank you much! We're also willing to tailor the Config items most > interesting to RubyGems to better suit how they're being used. Given the > above, I'd see the following scenario:
> The "ruby" executable on a windows machine would be > <jruby_home>/bin/jruby.bat. > The arch could be something like 'java' or maybe 'java-win32'. I'm > inclined to make it as OS-agnostic as possible, but the legend of complete > platform independence is long and storied. If we need the -platform bit, > it's probably doable. Preference would be to exclude. > RubyGems scripts would be installed such that they use jruby.bat instead > of 'ruby'. > If arch == 'java', I'd say it would be best to install both Windows and > *nix scripts, so they're all present. If arch provides more platform > information like 'win32', RubyGems could choose appropriately.
> -- > Charles Oliver Nutter @ headius.blogspot.com > JRuby Developer @ jruby.sourceforge.net > Application Architect @ www.ventera.com
-- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com
Charles O Nutter wrote: > FYI, if platform was needed, we could most easily provide > "java-windows", > "java-x86", or "java-windows-x86" (or some combination) given what the > JVM > tells us (System properties os.arch = x86 and os.name = windows). > Anything > beyond that would require massaging "windows" and "x86" into something > else.
RubyGems uses platforms for two things[1]. The obvious use is selecting the platform for possible gems to install[2]. The other use is when installing command file, RubyGems will create .cmd files for all the programs in the gem. I would imagine that we still need to do this for the JRuby version, right? It seems to me we need to differentiate between JRuby on windows vs JRuby on Unix. Perhaps the platform string is not the appropriate mechanizm for this. I'm will to hear alternatives.
-- Jim Weirich
[1] That I can think of off the top of my head. [2] Yes, the platform selection logic is currently rather weak. We hope to fix this in the near future.
> Charles O Nutter wrote: > > FYI, if platform was needed, we could most easily provide > > "java-windows", > > "java-x86", or "java-windows-x86" (or some combination) given what the > > JVM > > tells us (System properties os.arch = x86 and os.name = windows). > > Anything > > beyond that would require massaging "windows" and "x86" into something > > else.
> RubyGems uses platforms for two things[1]. The obvious use is selecting > the platform for possible gems to install[2]. The other use is when > installing command file, RubyGems will create .cmd files for all the > programs in the gem. I would imagine that we still need to do this for > the JRuby version, right? It seems to me we need to differentiate > between JRuby on windows vs JRuby on Unix. Perhaps the platform string > is not the appropriate mechanizm for this. I'm will to hear > alternatives.
I have not been following the thread as closely as I should have, so forgive me if this has been covered. 'java' is our platform for general Ruby behavior with the only exception of invocation scripts. So host OS is a significant discrimator for external/installation scripts, but not for general Ruby capabilities of the interpreter at large (like regardless of host OS we do not support File.tty?). It seems like this distinction may be a good option for gem creators.
-Tom
P.S. - I do things from cygwin on windows normally so I guess if I had a choice I would want a shell script in addition to a cmd file on Windows. I am sure I am an oddity in that regard and I suspect this is up to the gem-maker. I don't know if other have asked for this (and I know this has nothing to do with JRuby in particular).
-- + http://www.tc.umn.edu/~enebo +---- mailto:en...@acm.org ----+ | Thomas E Enebo, Protagonist | "Luck favors the prepared | | | mind." -Louis Pasteur |
At this point it's almost sounding like we should just leave our platform or 'arch' as 'java', and the default behavior for RubyGems would be to install both sh and cmd scripts. This would cover not only cases where you're on one platform or the other, but cases where we or someone else wants to ship a single distributable that will work anywhere Java does.
The 'java' arch would then also preclude any platform-native libraries, since we can't run them anyway. Those gem installs could come to a screeching halt rather than fail later on.
Jim, would adding such rules for a 'java' arch fit well with how RubyGems does such things?
> On Thu, 15 Jun 2006, Jim Weirich defenestrated me: > > Charles O Nutter wrote: > > > FYI, if platform was needed, we could most easily provide > > > "java-windows", > > > "java-x86", or "java-windows-x86" (or some combination) given what the > > > JVM > > > tells us (System properties os.arch = x86 and os.name = windows). > > > Anything > > > beyond that would require massaging "windows" and "x86" into something > > > else.
> > RubyGems uses platforms for two things[1]. The obvious use is selecting > > the platform for possible gems to install[2]. The other use is when > > installing command file, RubyGems will create .cmd files for all the > > programs in the gem. I would imagine that we still need to do this for > > the JRuby version, right? It seems to me we need to differentiate > > between JRuby on windows vs JRuby on Unix. Perhaps the platform string > > is not the appropriate mechanizm for this. I'm will to hear > > alternatives.
> I have not been following the thread as closely as I should have, so > forgive me if this has been covered. 'java' is our platform for general > Ruby behavior with the only exception of invocation scripts. So host > OS is a significant discrimator for external/installation scripts, but not > for general Ruby capabilities of the interpreter at large (like regardless > of host OS we do not support File.tty?). It seems like this distinction > may be a good option for gem creators.
> -Tom
> P.S. - I do things from cygwin on windows normally so I guess if I had > a choice I would want a shell script in addition to a cmd file on > Windows. I am sure I am an oddity in that regard and I suspect this is > up to the gem-maker. I don't know if other have asked for this (and I > know this has nothing to do with JRuby in particular).
> -- > + http://www.tc.umn.edu/~enebo +---- mailto:en...@acm.org ----+ > | Thomas E Enebo, Protagonist | "Luck favors the prepared | > | | mind." -Louis Pasteur |
-- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com
|
