This is sort of a crosspost of
http://groups.google.com/group/ruby-bundler/browse_thread/thread/11467b12c9338939,
because I’m beginning to suspect JRuby may be the culprit. Here’s the
thing: calling something like
jruby -S bundle exec jruby -S bundle list
will fail with
$HOME/bin/jruby/lib/ruby/site_ruby/1.8/rubygems.rb:861:in
`report_activate_error’: Could not find RubyGem bundler (>= 0)
(Gem::LoadError)
while the similar
ruby -S bundle exec ruby -S bundle list
will succeed, as well as something like:
jruby -S bundle exec bundle list
Now the original case seems a perfectly normal use case to me: when
invoking
jruby -S rake spec
the RSpec raketask will launch a new process that invokes
jruby -S bundle exec rspec [a bunch of rspec parameters]
which then fails with the original error. A regular ‘ruby -S rake
spec’ (aka. ‘rake spec’) will succeed, but the specs will fail,
because I’m dealing with JRuby specific code. I have to run rspec
under JRuby and I would like to be able to do that from rake, as part
of ‘jruby -S rake build’.
The problem seems to be that, on the first invocation, Bundler changes
the paths where Rubygems searches for gem and these changed paths are
carried over to the new process. As such, when JRuby calls the
‘bundle’ binary and the ‘bundle’ binary issues a “gem ‘bundler’”,
Rubygems is only looking in the paths of the bundle, where the bundler
gem isn’t present. (Now of course there is something weird going on,
because Bundler will (bundle list) happily tell you it is a member if
the current bundle, but even explicitly adding ‘bundler’ to the
Gemfile will not make the actual code available in vendor/bundle or
whatever other location you leave your bundled gems.)
As this is a difference between behavior under MRI and behavior under
JRuby and it could be due to things like GEM_PATH not being reset (I’m
just making up an example!), I thought posting it here may cause it to
be seen by someone that can shed some light on the issue.