[Rubygems-developers] env shebang always for JRuby
avatar at spellboundnet.com
Tue Apr 29 08:52:45 EDT 2008
On Monday 28 April 2008 10:40:09 am Charles Oliver Nutter wrote:
> JRuby ships with its "jruby" command as a shell script or batch file
> under Windows. This means that the default behavior for JRuby installing
> RubyGems is to always use an "env" shebang. However there are two
> problems with this right now:
> - we have to manually patch our copy of RubyGems every time we upgrade,
> to make sure it env-shebangs by default
> - RubyGems hardcodes the env shebang string to "ruby" rather than using
> the name of the current runtime's command (this may have been fixed?)
> At any rate, I'm looking for suggestions or a RubyGems fix that will
> save us having to manually patch this all the time. JRuby is not going
> to have a native startup command any time soon, so the env shebang is
> always going to be necessary.
I think that a of the discussions lately about gem vs. jgem, auto-default
env-shebangs, etc.... is IMO symptomatic of a larger problem in handing gem
executable binaries, and that problem is, "which interpreter do we use?". Now
that we have real situations where you have multiple interpreters actively
being used on a single system, our current method of selecting an interpreter
is no longer adequate.
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.
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!
- An interpreter-independent GEM_HOME. We need to statically define where gems
live so we gain platform/interpreter independence.
- A way for a gem to specify what interpreter has to be used.
- A way for the user to specify an alternate interpreter at install time.
(Maybe at execution-time, too?)
- And while we're tackling binary problems, let's see if we can solve the
problem of specifying the version of the binary we want to call (it currently
drives me nuts that I can't just say "rails version=1.2.6 some_project").
In the future, we may run into problems with language incompatibilities (which
I think is why the current structure imbeds versions). If things work out
well, I hope this problem will solve itself by having the language spec
independent of the implementation, and we can just add language version as an
additional type of dependency.
I don't want to get too heavy into implementation details until we agree on
the concepts, so.... what do you guys think?
> - Charlie
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
More information about the Rubygems-developers