We used `Bundler::RubyVersion.system.gem_version` for a long time, but I
changed this to `Gem.ruby_version` at
94f9643943. It's unclear why I did that
though since I believe it was unrelated to the fix in there.
Bootboot patches `Bundler::RubyVersion` to customize how Bundler works
with Ruby versions, and that change broke that.
Since it's unclear to me how to achieve what Bootboot is doing with the
current code, and there was no strong reason for the change, let's
restore it for now.
8ec36c6017
Improve error reporting for checksums, raises a new error class.
Solve for multi-source checksum errors.
Add CHECKSUMS to tool/bundler/(dev|standard|rubocop)26_gems.rb
26ceee0e76
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
This gets the specs passing, and handles the fact that we expect
checkums to be pinned only to a particular source
This also avoids reading in .gem files during lockfile generation,
instead allowing us to query the source for each resolved gem to grab
the checksum
Finally, this opens up a route to having user-stored checksum databases,
similar to how other package managers do this!
Add checksums to dev lockfiles
Handle full name conflicts from different original_platforms when adding checksums to store from compact index
Specs passing on Bundler 3
86c7084e1c
When @allow_cached is true, @allow_local is always true,
therefore, the #installed_specs will always be merged after #cached_specs
is called. This makes starting with installed_specs.dup redundant.
When #cached_specs is called because @allow_remote is true and
@allow_cached is false, then installed_specs will be added after
cached_specs based on @allow_local.
We never need to add installed_specs here, so don't.
49b38f9750
Rename Index#use(override = true) to #merge!
Rename Index @all_specs to @duplicates, it is not actually all specs.
@duplicates only holds specs that would have been overridden during a call to
Index#use or Index#merge!
Reduced dupes in @duplicates by not double adding the new spec to the
index and the @duplicates during #merge!
Reduce Array creation by using specialized methods when the one result
or no results are needed from the search.
47e91125db
If a legacy multi remote Gemfile depends transitively on a default gem,
then in standalone mode we'd fail to fetch the proper version from the
source that includes it, since we were adding it to `specs` (instead of
`remote_specs`), which was already including the default version of the
gem, and thus preventing the remote version from "overwriting that" and
being added to the index. We should add it to the `remote_specs` index
directly instead.
05f4f9dfc0
On legacy Gemfiles with multiple remote sources, where all of them
support the compact index API, we were still falling back to full
indexes.
Fixing this also allows to simplifying the code.
b1357c8e72
Previously, when sorting and comparing git Gemfile vs lockfile sources during
`bundler/setup` to figure out whether we need to re-resolve or not, we
would try to find the default branch if nothing more specific was
specified in the Gemfile.
If the git cache has been deleted thought, that would fail.
The error would still be swallowed (and the branch would simply not be
displayed), but trying to clone would still generate the side effect of
creating the parent folder for the clone.
That could affect non-writable systems that don't expect `bundler/setup`
to write to the filesystem at all.
To fix this, override `Bundler::Source::Git#identifier` to use
exclusively static information, so it does not even try to clone the
repo nor generate any side effects.
582eb2ef39
We have some flags that limit running git commit commands under certain
situations, for example, when running under `--local`. However, those
should only affect remote git operations, not local read-only operations
like `git --version`, or `git rev-parse --abbrev-ref HEAD`.
This commit refactors things to achieve that.
By doing this, the `#to_s` representation of a source is more
consistent, since we don't get any errors when reading the checked out
branch, and we avoid some flip-flop lockfile issues.
4a529fce81
It's the only part that needs "root folder resultion" to figure out the
folder for the cache, but it's only needed for some things, so run that
logic lazily when needed.
c7b9eae0bc
If Gemfile has a lot of dependencies, we have an optimization that uses
the full index in that case, assuming it's going to be faster.
I think this is an old optimization that predates compact index API
times, I believe we no longer need it these days.
Also, since a few releases ago we check for circular dependencies when
resolving by looping through all versions of each name and removing
those that have circular dependencies that would trip up the resolver.
This loop becomes actually very slow when full indexes are used because
to find dependencies of a gemspec, we need to explicitly fetch the
marshaled gemspec (`gemspec.rz` endpoint) for it, so the optimization
has the opposite effect of making things very slow.
2f46289bd3
Since Bundler 2.4, we will try to checkout any branch specified in the
Gemfile, while until Bundler 2.3 we would directly checkout the locked
revision.
This should not make any difference in most situations, but in some edge
cases, like if the branch specified in the `Gemfile` has been renamed,
but the locked revision still exist, it causes an error now while before
it would update the lockfile without issues.
I debated which behavior was best, since I was not sure. But my
conclusion is that if the situation does not require expiring the
lockfile source in favor of the Gemfile source, we should use the locked
revision directly and proceed happily. So I restored Bundler 2.3
behavior.
I think this is consistent with how yanked gems are handled, for example.
Of course, if explicitly updating the git source itself, or all gems, we
will still get any errors like missing branches related to the git source.
Currently, the --no-install option to `bundle package` is totally
ignored for git sources. This can have very strange effects if you have:
- a git-sourced gem,
- with native extensions,
- whose extconf.rb script depends on another gem,
- which is installed from Rubygems in the gemfile.
In that circumstance, `bundle package --no-install --all` will download
the Rubygems dependencies to `vendor/cache` but NOT install them. It
will also check out the git gems to `vendor/cache` (good), and attempt
to build their native extensions (bad!).
The native extension build will fail because the extconf.rb script crashes,
since the dependency it needs is missing.
I implemented a fix for this in `source/git.rb`, since this is analogous
to what's happening in `source/rubygems.rb`. I do admit though the whole
thing is a little strange though - an "install" method that.... proceeds
to look at a global flag to not install anything.
Add test to confirm cache respects the --no-install flag
5a77d1c397
Co-authored-by: KJ Tsanaktsidis <kj@kjtsanaktsidis.id.au>
This is a regression from cf749f8ffa. The
funny thing is that we have a spec for this feature, so it was unclear
how we regressed here. It turns out there was a bug in one of our
negative matchers checking that gems ARE NOT included in a bundle.
This commit fixes the bug in the negative matcher and reverts
cf749f8ffa (with a slightly simpler diff).
3f9a4ff32a
Previously we would instantiate two different packages and extract the
specification from the package twice for each gem installed. We can
reuse the installer for this so that we just need to do it once.
e454f850b1
