There's no reason to call `converge_specs` when adding additional
lower bound requirements to prevent downgrades, and it actually causes
the extra requirements to be missed sometimes.
Loop over the originally locked specs directly, adding the additional
precaution of not adding the requirement if the Gemfile dependency has
changed and it no longer matches the locked spec.
5154506912
When Bundler refuses to install in frozen mode, sometimes it would
incorrectly claim that some dependencies have been added to the Gemfile
when that's not really the case. Fix that by making sure
`locked_dependencies` always has all locked dependencies, even when
unlocking,
Additionally, the suggestion to run `bundle install` is also confusing
when unlocking, since `bundle update` is what has been run. So skip that
part as well when unlocking.
64d84ad7d8
When converging specification to pass the set of versions that should be
preserved from the lockfile during resolution, we should make sure all
top level gems are considered, and only exclude those gems themselves
(and not their dependencies) if their locked versions happen to not be
satisfied by an edited Gemfile.
ed2f1b7b88
An old platform related bug fix made some existing lockfiles no longer
work because they included invalid platforms. So to make it backwards
compatible, code was added to remove invalid platforms from the lockfile
before resolution. This is skipped though when Gemfile has changed
dependencies because in that case we will be re-resolving anyways.
However, in the `bundle update` case, the detection of "dependencies
have changed" was not actually working making Bundler remove all
platforms and not be able to resolve.
6452adfd62
There is another place artifice usage was making the copy of vendored
http in ruby-core be loaded instead of the one under test.
Remove unnecessary usage of artifice.
d2488199b0
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
Since we started locking the specific platform in the lockfile, that has
created an annoying situation for users that don't develop on Linux.
They will create a lockfile on their machines, locking their local
platform, for example, darwin. But then that lockfile won't work
automatically when deploying to Heroku for example, because the lockfile
is frozen and the Linux platform is not included.
There's the chance though that resolving against two platforms (Linux +
the local platform) won't succeed while resolving for just the current
platform will. So, instead, we check other platform specific variants
available for the resolution we initially found, and lock those
platforms and specs too if they satisfy the resolution.
This is only done when generating new lockfiles from scratch, existing
lockfiles should keep working as before, and it's only done for "ruby
platforms", i.e., not Java or Windows which have their own complexities,
and so are excluded.
With this change, we expect that MacOS users can bundle locally and
deploy to Heroku without needing to do anything special.
5f24f06bc5
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
1. Use the checksum provided by the server if provided: provides security
knowing if the gem you downloaded matches the gem on the server
2. Calculate the checksum from the gem on disk: provides security knowing
if the gem has changed between installs
3. In some cases, neither is possible in which case we don't put anything
in the checksum and we maintain functionality as it is today
Add the checksums to specs in the index if we already have them
Prior to checksums, we didn't lose any information when overwriting specs
in the index with stubs. But now when we overwrite EndpointSpecifications
or RemoteSpecifications with more generic specs, we could lose checksum
info. This manually sets checksum info so we keep it in the index.
de00a4f153
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
This error message is also printed when using `bundler/setup` in frozen
model, so we're not necessarily installing any gems when it happens.
This new message play nicer with all situations.
6874bbacce
When `--conservative` is passed, explicit unlocks are set for top level
gems via `@unlock[:gems]`, so that only those particular gems are
allowed to be updated.
When we compute the "base resolve" from the lockfile (the set of gems
whose versions should be kept pinned by the resolver), we always exclude
gems explicitly unlocked through `@unlock[:gems]` from it. This is done
by the `converge_specs` method.
However, the `converge_specs` method is also used for figuring out
additional lower bound requirements from the lockfile. But in this case,
even if gems are explicitly unlock in `@unlock[:gems]`, we still want to
add the additional requirement, so that gems are not downgraded by the
resolver.
So the solution is to move the line filtering out gems in
`@unlock[:gems]` from the `converged_specs` method out of that method,
so that it only applies for computing the "base resolve", but not the
addtional lower bound requirements.
405119bd7b
These specs were monkeypatching `RUBY_VERSION`, but that obviously
doesn't change the running ruby to behave any different.
The removal of some features, in particular, `String#untaint`, made
these specs fail, because untaint is no longer available under ruby-core
and bundler calls `untaint` when `RUBY_VERSION` is less than "2.7",
which these specs were overwriting it to be.
Rewrite these specs to not overwrite `RUBY_VERSION`, but still test the
same things.
e8c7b92901
