| Age | Commit message (Collapse) | Author |
|---|
|
|
|
https://github.com/rubygems/rubygems/commit/9ea1539b08
|
|
https://github.com/rubygems/rubygems/commit/0c3a65871a
|
|
https://github.com/rubygems/rubygems/commit/d5dce93167
|
|
The original implementation of this flag was too naive and all it did
was restricting gems to locally installed versions if there are any
local versions installed.
However, it should be much smarter. For example:
* It should fallback to remote versions if locally installed version
don't satisfy the requirements.
* It should pick locally installed versions even for subdependencies not
yet discovered.
This commit fixes both issues by using a smarter approach similar to how
we resolve prereleases:
* First resolve optimistically using only locally installed gems.
* If any conflicts are found, scan those conflicts, allow remote
versions for the specific gems that run into conflicts, and
re-resolve.
https://github.com/rubygems/rubygems/commit/607a3bf479
Co-authored-by: Gourav Khunger <gouravkhunger18@gmail.com>
|
|
Instead of having to do a complete pass after resolve.
To do this, we add to the ruby group all the platform specs with the
same dependencies as the ruby specs.
https://github.com/rubygems/rubygems/commit/e50415f2a6
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
While working on locking multiple platforms by default, I got an
infinite resolution loop in one of our resolver specs.
The culprit ended up being that when dealing with lockfile specs with
incomplete dependencies (spec appears in lockfile, but its dependencies
don't), those specs were not being properly expired and that tripped up
resolution.
The issue for some reason only manifests when dealing with multiple
lockfile platforms, that's why it only manifested when working on
locking multiple platforms by default.
https://github.com/rubygems/rubygems/commit/4ca72913bb
|
|
This reverts commit 69580f8b72f41c58cae57d1ada4db909922b3891.
|
|
unlocking
Bundler is very conservative by default, trying to preserve versions
from the lockfile as possible, and never downgrading them. However, when
it runs into a resolution error, it still tries to find a valid
resolution.
This fallback behavior was too "brute-force" though, completely
unrestricting any gem found in the resolution conflict, and that could
lead to direct dependencies being downgraded in some edge cases.
Instead, unlock things a bit more carefully:
* First try unlocking fully pinned indirect dependencies, but leave a
lower bound requirement in place to prevent downgrades.
* Then try unlocking any fully pinned dependency, also leaving a lower
bound requirement in place.
* Finally completely unrestrict dependencies if nothing else worked.
https://github.com/rubygems/rubygems/commit/7f55ed8302
|
|
Recent bugs fixed made me realize we were relying on state too much
here. We only need to keep incomplete specs to be able to expire them
and retry resolution without them locked. If we use a separate class, we
can do that more transparently and handle them just like we handle
"missing specs".
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Pick from https://github.com/rubygems/rubygems/commit/5ace20dbecfeaf09fba5f616193f3cfcff70ba00
Notes:
Merged: https://github.com/ruby/ruby/pull/7203
|
|
https://github.com/rubygems/rubygems/pull/5960
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|
https://github.com/rubygems/rubygems/commit/6214d00b2315ed37c76b1fbc1c72f61f92ba5a65
Notes:
Merged: https://github.com/ruby/ruby/pull/6578
|
|
https://github.com/rubygems/rubygems/commit/16c3535413afebcdbab7582c6017c27b5da8a8dc
Notes:
Merged: https://github.com/ruby/ruby/pull/6326
|
