First I'll say this isn't really related to the shebang thing. The env
shebang hardcoding "/usr/bin/env ruby" would affect MRI too if you had
an sh script not named 'ruby' you wanted to use as your launcher. That's
essentially the case here; the 'jruby' command is a bash script that
launches a JVM running JRuby. So that should be fixed to use the
*actual* command name instead.
And the fact that we need env-shebangs by default is unrelated as
well...it all comes back to the 'jruby' command being a bash script.
Second, I'll respond to a couple of your points.
Donavan Pantke wrote:
First, I want to stress that there should only be one gem repo on a system.
RubyGems is platform-agnostic and handles selecting code based on interpreter
platform well. Having multiple system-wide gem repositores is asking for
trouble, since they all have to share a single PATH, and this problem is what
led to "gem" vs. "jgem". The easiest way to get rid of strange PATH problems
is to have one RubyGems managing it.
I think it should be an option that you have one repo, but I prefer to
keep them separate myself. It certainly shouldn't be the default, since
lots and lots of people install and use JRuby as their username,
sometimes with a couple installs...and it ships with a couple IDEs,
which package it in a subdir. Some people want to use a shared repo,
some don't.
So how can RubyGems select between several interpreters? We'll need a couple
of things to make this happen:
- A way to determine the default interpreter on the system.
This is easy to do on POSIX (symlink!), not so easy in Windows. Luis, do you
have any thoughts on this? Remember, we don't really care what interpreter is
called by "gem", so long as "gem" will run!
It would *seriously* suck if the only way to get rubygems to choose
JRuby was by using a symlink...and the 'jruby' command isn't an
executable, so gems installed without shebangs would not work wen you
switched from ruby to jruby.
- An interpreter-independent GEM_HOME. We need to statically define where gems
live so we gain platform/interpreter independence.
If you like, you can do that now and have JRuby access an existing
GEM_HOME. I'm not sure people do it though.
- A way for a gem to specify what interpreter has to be used.
This would definitely be nice to have in the gem metadata, since there's
conceivably going to be five implementations to choose from that might
all have their own extension mechanisms (ruby 1.8/1.9, jruby, rubinius,
macruby [ObjC extensions?], ironruby).
- A way for the user to specify an alternate interpreter at install time.
(Maybe at execution-time, too?)
Maybe...starts to get a little cumbersome at that point though.
- Charlie
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
