When running the bin/rake Bundler binstub, the binstub sets
ENV['BUNDLE_GEMFILE'] which is inherited by calls to the rake
environments of the Projects. The top level Gemfile only includes Rake
and Thor, so it's not surprising that the builds can't continue. MRI
1.9.2 appears to be able to work around this with "export
RUBYOPT=rubygems", but that seems inelegant at best.
This change determines if the Rakefile was launched through a bundled
rake; if so, it uses Bundler.with_clean_env (and deletes the
BUNDLE_GEMFILE for good measure; necessary if you use the binstub, less
necessary if you use "bundle exec rake") and instead of running 'rake',
it runs 'bin/rake' to force the use of the Project rake binstub, forcing
the use of the correct Gemfile and bundler environment.
The non-bundler path works as it always has.
When using more than one ruby, "bundle install --binstubs" will
continually be overwriting the binstubs put into bin/.
This patch builds on request #22 (Rakefile bundler awareness) and makes
it possible to specify an alternative binstub directory at install and
run-time. If using an alternative binstub directory, you can't run the
tests with the :default task anymore, you need to use :runtests[rake] to
specify which rake will be called (e.g., jruby-bin/rake if you used
Rake is smarter than I initially assumed about passing parameters to
dependent tasks. This means that the :setup task does not require an
explicit body and does not require Rake::Task#invoke for its dependent
tasks, making rspec-dev Rakefile closer to being drake-compatible.