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 > [email protected] > http://rubyforge.org/mailman/listinfo/rubygems-developers > _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
