- ### Problem Since https://github.com/ruby/rubygems/pull/9131, we are now compiling make rules simultaneously. The number of jobs is equal to the number of processors. This may be problematic for some users as they want to control this value. ### Solution The number of jobs passed to `make` will now be equal to the `BUNDLE_JOBS` value. ### Side note It's also worth to note that since Bundler installs gems in parallel, we may end up running multiple `make -j<JOB>` in parallel which would cause exhaust the number of processors we have. This problem can be fixed by implementing a GNU jobserver, which I plan to do. But I felt that this would be too much change in one PR. https://github.com/ruby/rubygems/commit/d51995deb9
- Fix https://github.com/ruby/rubygems/pull/9188 - This message is a bit misleading because it always outputs one extra specs, which is Bundler itself. This is now fixed when the message is about to be output. https://github.com/ruby/rubygems/commit/70b4e19506
- Fix https://github.com/ruby/rubygems/pull/9186 - ### Problem Running `bundle pristine` in a Gemfile where there is many git gem pointing to the same repository will result in a error "Another git process seems to be running in this repository". ### Context This error is a regression since https://github.com/ruby/rubygems/commit/a555fd6ccd17 where `bundle pristine` now runs in parallel which could lead to running simultaneous git operations in the same repository. ### Solution When Bundler pristine a git gem it does a `git reset --hard` without specifying a path. This means the whole repository will be reset. In this case, we can leverage that by just pristining one gem per unique git sources. This is also more efficient. https://github.com/ruby/rubygems/commit/710ba514a8
When running a fresh `bundle install` with gems that contains executables, Bundler will generate binstubs but soon after will remove them. This is a regression introduced in https://github.com/ruby/rubygems/commit/573ffad3ea4a. This results in doing `bundle install && bundle exec foo` to raise an error saying `foo` couldn't be found. This issue only appears if `BUNDLE_CLEAN` is set. At the end of the installation process, when Bundler has installed gems and generated binstubs, it runs the cleanup. 1. It [detects](https://github.com/ruby/rubygems/blob/4f8aa3b40cded3465bb2cd761e9ce7f8673b7fcb/bundler/lib/bundler/runtime.rb#L182) the executable for the current specs 2. Any existing executables not detected is then removed https://github.com/ruby/rubygems/blob/4f8aa3b40cded3465bb2cd761e9ce7f8673b7fcb/bundler/lib/bundler/runtime.rb#L194. The issue being that 1. now returns an empty array where as it should return the executables of the gems from the current bundle. The problem is in https://github.com/ruby/rubygems/commit/573ffad3ea4a where we removed the `executables` method from the `EndpointSpecification`. When Bundler reads the lockfile, it creates a `EndpointSpecification` object for each spec. At this point, the EndpointSpecification doesn't know about the `executables` of a gem. Once Bundler fetches the `gemspec` from the remote, it swaps the the "spec" with the real one and from here knows what executables the gem has. Reintroduce the `executables` method and the `bindir` in the EndpointSpecification class. From what I'm seeing, the removal of those wasn't needed to resolve the issue where Bundler remembers CLI flags. This is probably an oversight. https://github.com/ruby/rubygems/commit/b47f6b0247
Add fallback to `require` when `require_relative` fails to load native extensions. This addresses an issue on RHEL-based Linux distributions where Ruby scripts and built native extension shared libraries are installed in separate directories. https://github.com/ruby/rubygems/commit/68599bd107
It would be simpler to do `options[:lockfile] ||= ENV["BUNDLE_LOCKFILE"]`, but that doesn't work as `options` is frozen. Fixes https://github.com/ruby/rubygems/pull/9117 https://github.com/ruby/rubygems/commit/6e3603a0e9