In some projects, for example those with 10s of local gemspecs, use of `git ls-files` for spec.files, or specs requiring significant source to get at a spec.version; this change to cache load_gemspec results in notable performance gains. The cache also avoids loading these same gemspecs repeatedly with different LOAD_PATH values.
Restoring the original ENV generally restored the RUBYOPT changes, but certain use cases leak through. This commit ensures that the ENV is truely clean by always checking for RUBYOPT changes and zapping them if they do exist. This commit fixes #1604 (second attempt)
This method provides a way to access the Gem::Specification object generated from the gemspec file from within a Rakefile generated by `bundle gem'. You can keep DRY by using it to pull in attributes like `test_files', `extra_rdoc_files' and `extensions' for building tasks like `test', `rdoc' and `compile', respectively.
For implementations like Rubinius that can run from a source directory without installing and which do not overwrite gem binary wrappers in system directories, it is possible to invoke the Rakefile with eg 'rbx -S rake spec' while the system Ruby is on PATH as 'ruby' and 'gem'. This results in the system Ruby running the rake subprocesses instead of Rubinius as intended. These changes use Gem.ruby, which returns the path to the Ruby implementation running rake and use -S to search for the gem bin wrapper on PATH. Rubinius prepends distinguished directories when processing -S so that gems installed into Rubinius are found first. The explicit requiring of rubygems may be controversial. Evan said it was ok but the rest of the changes stand on their own if it's desirable to remove the require.
… right rubyopts options is enough This makes bundle exec rake environment of this https://gist.github.com/d61b87f53277efd6079e Gemfile, 17% faster
--- The binstubs generated by Bundler currently require both rubygems and bundler to be installed in order to execute: requirements not guaranteed at runtime for a standalone bundle. This introduces a separate method to generate binstubs when generating a standalone bundle. It first adds the root of the standalone to the load path, and then requiring `bundler/setup` from there. I was on the fence whether to leave the load path alone and load bundler/setup.rb directly via its path relative to the generated executeable, but in the end decided to go the way I did so that application code requiring bundler/setup will continue to function. Im pretty excited about the standalone feature, and I hope that this makes it into 1.1