[Rubygems-developers] env shebang always for JRuby

Donavan Pantke 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?

Thanks!
Donavan

> 
> Thoughts?
> 
> - Charlie
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
> 




More information about the Rubygems-developers mailing list