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 6/12/06, Charles O Nutter [email protected] 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
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.
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 W.
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.
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 W.
[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.
On Thu, 15 Jun 2006, Jim W. defenestrated me:
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).
On 6/13/06, Jim W. [email protected] 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.
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?
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 W.
Or a --platform= switch or something similar…