[Rubygems-developers] env shebang always for JRuby

Stephen Bannasch stephen.bannasch at deanbrook.org
Tue Apr 29 10:46:58 EDT 2008


At 8:52 AM -0400 4/29/08, 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 like the idea but I recommend just the opposite for now -- always use separate gem repositories for different Ruby VMs.

  http://rubyforge.org/pipermail/rubygems-developers/2008-April/003737.html

Two basic problems: what native code gets built and which commands are installed in whatever passes for "bin/".

When a gem is installed that requires compilation and linking (or more generally any custom build products that are specific for a particular Ruby VM and OS -- for example an executable shell script) during the install the products of that install will only work when it is later used with the same Ruby VM and OS it was installed with. More about this problem here:

  http://rubyforge.org/pipermail/rubygems-developers/2008-April/003717.html

I mention the idea of lazy installation in that message: when a Gem with native code is installed using Ruby VM-A and later first used with Ruby VM-B perhaps the compilation and install part of the process can be run again by Ruby VM-B.

Or perhaps with a system GEM (which of course needs a system Ruby) alternate Ruby VM's could register themselves when installed.

There is also the problem of conflicting "bin/" commands requiring in a simple case different shebang lines.

A subtlety with the JRuby VM is that the Ruby is running on both a Java OS (in effect) and a host OS and has strong capabilities for interacting with both systems. This doesn't usually matter for most Java programs because they often only deal with the host OS mediated through Java libraries -- but among many other things Ruby is a systems programming language and Ruby scripts written to support these tasks often have code written to operate differently on different host OS platforms. In these cases code written to also run on JRuby may need to take into account that it is running both in JRuby on Java AND on which host OS Windows, MacOS, etc.

>- A way for a gem to specify what interpreter has to be used.

Or which interpreters may be used (all in the simple case) and which may not be used.


More information about the Rubygems-developers mailing list