Since now every functionality that changes in Bundler 4 is under a
setting, we can enable that setting to test the new functionality,
without having to run our full CI twice.
This can actually be seen as increasing coverage, because Bundler 4
functionality will now be tested on Windows, MacOS, or any other
environment where previously "Bundler 4 mode" was not running.
1cb3e009fc
This has the following benefits:
* Avoid duplicated work in some specs that first build a repo, and then
overwrite it with a completely different set of gems.
* Reduce RSpec nesting and improve readability.
* The change also made surfaces several specs that were incorrect since
they were unintentionally not testing the right thing.
ed430883e0
A spec needed changes because now loading the default `json` prints a
warning about `ostruct` getting loaded although it will be removed in
the future. Use a different default gem to test this.
7415a66906
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
Recent refactorings in test suite to not load `pathname` for launching
Bundler subprocesses make some specs fail due to the warnings Ruby prints
when autoloading `pathname` under a namespace. But enabling this spec
also reproduces the hard error it produces on truffleruby.
e47cd78081
For backwards compatibility, make sure default gems are still used as a
last resort when materializing, in case no remote, cached, or installed
specs are found.
93788f689f
Even if all gems are properly installed and no resolve is needed, we
recently started always reading all packages in `vendor/cache` and
extracting specifications from them.
This commit fixes the problem by longer making considering cached specs
the default and only enable them when a resolve is actually needed.
edeb2c42bf
We have some places that already use `bundle config auto_install true`,
ie:
7a144f3374/bundler/lib/bundler/cli.rb (L11)
This applies the same logic (copy and pasted) to happen when you
`require "bundler/setup"`.
bb3c922341
If a gem is specified in the Gemfile (or resolved as a transitive
dependency), it's always resolved from remote/installed sources. Default
gems are only used as a fallback for gems not included in the bundle.
I believe this leads to more consistent behavior and more portable apps,
since all gems will be installed to the configured bundle path,
regardless of whether they are default gems or not.
091b4fcf2b
Looks for the CHECKSUMS section in the lockfile, activating the feature
only if the section exists. Without a CHECKSUMS section, Bundler will
continue as normal, validating checksums when gems are installed while
checksums from the compact index are present.
2353cc93a4
We lock the checksum for each resolved spec under a new CHECKSUMS
section in the lockfile.
If the locked spec does not resolve for the local platform, we preserve
the locked checksum, similar to how we preserve specs.
Checksum locking only makes sense on install. The compact index
information is only available then.
bde37ca6bf
We were setting the wrong `extension_dir` for git specs stubs
Additionally, the call to `self.extension_dir` was loading the
remote spec, which was avoidable since the stub had an extension dir
(and in fact its #gem_build_complete_path does exactly what we want
anyway)
Finally, now set the base_dir when loading the remote_spec from a
stub specification, since the git source sets the base dir for stubs
based on where the spec _will_ be installed to, and we want to preserve
that so the base_dir for the loaded spec & the stub are the same
a94acb465b
The dedicated method `File.path` to deal with pathname-like objects
has been provided since ruby 1.9.0.
Also adds a test for rubygems/rubygems#6837.
258c6eda80
