buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Bannasch <>
Subject Re: Buildr 1.3 is out!
Date Wed, 07 May 2008 20:10:29 GMT
At 4:49 PM -0700 5/1/08, Assaf Arkin wrote:
>New and improved in 1.3:

Looks great.

One comments regarding using it with jruby. This page:

starts by suggesting adding the path to JRuby's bin/ dir to the end of the path and executing:

  gem install buildr

I'll bet that most of the OS systems that have JRuby installed already have Ruby installed
and that the system app bin/ directories will already have a gem command installed there.
In this case the gem install command will install buildr for the system Ruby (presumably MRI).

I think you could simplify your instructions and lessen some users problems by telling people
to always run a JRuby system script like gem with this form of the command:

  jruby -S gem install buildr

This should always work. This form is recommended in the JRuby wiki getting started page:


Because rubgems doesn't have any explicit support for coordinating a gem repository for multiple
Ruby VM installations on one system a number of people are having troubles when they inadvertently
create a gem repository shared by MRI and JRuby.

I recommend always using separate gem, lib/, and bin/ locations for a JRuby install and always
running JRuby versions of the Ruby system commands with the 'jruby -S' prologue. Getting into
this habit helps people differentiate when they are running JRuby instead of Ruby.

There have been some recent inconclusive threads on the rubygems-dev list about these issues.
The following is quoted from a recent post I made:

>My suggestion below is based on the initial assumption that jruby (as an alternate ruby
VM) is installed in a manner in which there are separate lib gem and bin directories from
the standard system Ruby. In addition IF a path to JRUBY_HOME/bin is put on the PATH env variable
it is only put after a path reference to any system Ruby and it's associated system bin/ directory.
>I haven't seen evidence that any other install strategy for an alternate Ruby VM will
work. Nobody has yet described how a shared gem repository could work reliably when native
code is involved under the current implementations.
>It is the responsibility of JRuby (and packagers of JRuby) to make this separation of
gem, bin, and lib directories from any other installed Ruby VM the likely outcome of various
install processes.
>Assuming an install as described above I suggest keeping the installed gem command as
'gem' for all alternate Ruby VMs and possibly adding a jgem command to the standard system
location for bin commands. The jgem command would execute:
>  /path/to/jruby/bin/jruby -S gem
>This way anytime you are expecting to be using MRI (or another standard system Ruby VM)
typing gem will do what you expect.
>To run the JRuby gem you can type:
>  jgem
>OR if you have added JRUBY_HOME/bin to your path you can also type:
>  jruby -S gem
>If my conclusion about keeping separate gem, bin, and lib directories is correct for alternate
Ruby VMs AND the actual installation of multiple Ruby VMs on multiple platforms can be introspected
in a reliable way THEN it **might** be useful for RubyGems to refuse to upgrade itself or
install a gem in a mixed repository without using some type of --force parameter.


View raw message