Hello Rubyists! 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?
on 2006-06-12 22:54
on 2006-06-13 19:07
On 6/12/06, Charles O Nutter <email@example.com> wrote: > 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. ;) -austin
on 2006-06-13 22:35
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 2006-06-14 06:59
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". Actually, rubygems uses: File.join(Config::CONFIG['bindir'], Config::CONFIG['ruby_install_name']) What are the bindir and ruby_install_name values set to under JRuby? The RubyGems teams is very willing to work this out. -- Jim Weirich
on 2006-06-14 17:29
On 6/13/06, Jim Weirich <firstname.lastname@example.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. Actually, rubygems uses: > > File.join(Config::CONFIG['bindir'], > Config::CONFIG['ruby_install_name']) > > 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.
on 2006-06-14 17:33
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 2006-06-14 20:12
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. The obvious use is selecting the platform for possible gems to install. 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  That I can think of off the top of my head.  Yes, the platform selection logic is currently rather weak. We hope to fix this in the near future.
on 2006-06-14 20:43
On Thu, 15 Jun 2006, Jim Weirich defenestrated me: > RubyGems uses platforms for two things. The obvious use is selecting > the platform for possible gems to install. 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).
on 2006-06-14 21:56
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 2006-06-14 23:06
Charles O Nutter wrote: > Jim, would adding such rules for a 'java' arch fit well with how > RubyGems > does such things? I think that would work. Perhaps we can add a --no-cmd switch to override if somebody /really/ didn't want the .cmd files. -- Jim Weirich
on 2006-06-14 23:10
Or a --platform= switch or something similar...