The generic Ruby platform was getting unconditionally added in
truffleruby, preventing resolution in situations where there's no
generic ruby version (sorbet-static). Instead, the generic platform
should be considered per dependency, not globally.
a96afc5351
My application spends more than 30% of time during `bundle update`
comparing versions due to versions being sorted inside
next_package_to_try. This has been addressed in pub_grub by defining a
strategy interface (a `#next_package_and_version` method) which allows
consumers to have finer control over the heuristic to select the next
package to try.
This commit implements the new strategy interface to remove extraneous
version sorting (previously in next_package_to_try) since only the final
count of versions is used.
Combined with a previous change to pub_grub (already applied to
Bundler), this commit results in `bundle update` taking only half the
time it did on 2.6.5.
62f69e27f0
In a large application I profiled allocations while running `bundle
update` and found that this method was ~60% of allocations while
resolving (and Candidate#<=> is almost half of the total runtime).
This commit removes the array allocation in Candidate#<=> (and similar
methods since the implementations are so simple). The array is always
the same two elements so they can just be compared directly.
6a7c411ba7
Resolver had internal logic to prioritize locked versions when sorting
versions, however part of it was not being actually hit because of how
unlocking worked in the resolver: a package was allow to be unlocked
when that was explicit requested or when the list of unlocks was empty.
That did not make a lot of sense and other cases were working because
the explicit list of unlocks was getting "artificially filled".
Now we consider a package unlocked when explicitly requested (`bundle
update <package>`), or when everything is being unlocked (`bundle
install` with no lockfile or `bundle update`).
This makes things simpler and gets the edge case added as a test case
working as expected.
b8e55087f0
They use less memory that way.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
### After
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
a4ef9c5f56
Sometimes we'll resolve using bare `Gem::Dependency` instances rather
than `Bundler::Dependency` instances, which is fine, simpler, and saves
some memory.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 277.48 MB (3384318 objects)
Total retained: 117.53 MB (1338657 objects)
### After
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
c6dc2966c5
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.
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.
e50415f2a6
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.
4ca72913bb
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.
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".
