- ### 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

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

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

This allows for specifying the lockfile to read and write. It mirrors
the --gemfile option, and has higher priority than the lockfile
method in the Gemfile. It also mirrors the bundle lock --lockfile
option.

When the --lockfile option is used, it is applied twice. First, before
the Gemfile is read, to specify the lockfile to operate on, and again
after the Gemfile is read, so that if the Gemfile has a lockfile
method that overrides the defintion's lockfile, the --lockfile option
still has higher precedence.

https://github.com/ruby/rubygems/commit/17acdd4a89

This allows for the same behavior as including `lockfile false`
in the Gemfile. This allows you to get the behavior without
modifying the Gemfile, which is useful if you do not control the
Gemfile.

This is similar to the --no-lock option already supported by
`gem install -g Gemfile`.

https://github.com/ruby/rubygems/commit/6c94623881

Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>

This allows you to specify the lockfile to use. This is useful if
you want to use different lockfiles for different ruby versions or
platforms. You can also skip writing the lockfile by using a false
value.

https://github.com/ruby/rubygems/commit/2896aa3fc2

Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>

This is a first pass to improve the way errors are handled and raised in
bundler's tests. The goal is to clean up tests and modernize them -
these were some obvious areas that could be cleaned up.

- Instead of raising "ZOMG" in the load error tests, it now tests for
the actual error and gem raising.
- Improve error messages where applicable.
- All errors raise a specific error class, rather than falling back to a
default and just setting a message.
- Removed arguments and `bundle_dir` option from `TheBundle` class as it wasn't
actually used so therefore we don't need to raise an error for extra
arguments.
- Removed error from `BundlerBuilder`, as it won't work if it's not
`bundler`, also it never uses `name`. The only reaon `name` is passed
in is because of metaprogramming on loading the right builder. I
think that should eventually be refactored.
- Replaced and removed `update_repo3` and `update_repo4` in favor of
just `build_repo3` and `build_repo4`. Rather than tell someone writing
tests to use a different method, automatically use the right method.

https://github.com/ruby/rubygems/commit/68c39c8451

https://github.com/ruby/rubygems/commit/d3baf4110e

Always build gems with RubyGems programmatically

https://github.com/ruby/rubygems/commit/5cc0c34e64

https://github.com/rubygems/rubygems/commit/59b909fa74