summaryrefslogtreecommitdiff
path: root/lib/bundler/resolver
AgeCommit message (Collapse)Author
8 daysMove most of Bundler::GemHelpers to Gem::PlatformSamuel Giddins
This will help centralize wheel platform selection logic eventually Signed-off-by: Samuel Giddins <[email protected]>
2025-03-27[rubygems/rubygems] Implement pub_grub strategy interfaceHartley McGuire
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. https://github.com/rubygems/rubygems/commit/62f69e27f0
2025-03-24[rubygems/rubygems] Consistently use "lockfile" over "lock file"David Rodríguez
https://github.com/rubygems/rubygems/commit/e891be9197 Notes: Merged: https://github.com/ruby/ruby/pull/12968
2025-03-13[rubygems/rubygems] Remove array allocation from Candidate#<=>Hartley McGuire
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. https://github.com/rubygems/rubygems/commit/6a7c411ba7
2025-02-18[rubygems/rubygems] Fix locked gems being upgraded when locked dependencies ↵David Rodríguez
are incorrect 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. https://github.com/rubygems/rubygems/commit/b8e55087f0
2025-02-06[rubygems/rubygems] Move expanding dependencies with metadata to ↵David Rodríguez
specification classes https://github.com/rubygems/rubygems/commit/7f921aa46e
2025-02-06[rubygems/rubygems] Metadata dependencies can be `Gem::Dependency` instancesDavid Rodríguez
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) https://github.com/rubygems/rubygems/commit/a4ef9c5f56
2025-02-06[rubygems/rubygems] Remove unnecessary remapping of dependenciesDavid Rodríguez
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) https://github.com/rubygems/rubygems/commit/c6dc2966c5
2025-01-14[rubygems/rubygems] Don't remove platform specific variants from the ↵David Rodríguez
lockfile unless necessary Even if they don't match the current Ruby version, they could still work in other rubies. So it's better to keep them. https://github.com/rubygems/rubygems/commit/9a3e583b0c Notes: Merged: https://github.com/ruby/ruby/pull/12568
2025-01-14[rubygems/rubygems] Extract `SpecSet#version_for`David Rodríguez
https://github.com/rubygems/rubygems/commit/a76fd6d3bf Notes: Merged: https://github.com/ruby/ruby/pull/12568
2024-11-26[rubygems/rubygems] Remove no longer necessary codeDavid Rodríguez
https://github.com/rubygems/rubygems/commit/9ea1539b08
2024-11-26[rubygems/rubygems] Create LazySpecifications directly with ↵David Rodríguez
most_specific_locked_platform So there's no need to pass it around in so many places. https://github.com/rubygems/rubygems/commit/784ab7481b
2024-11-26[rubygems/rubygems] Enable `Performance/MapCompact` copDavid Rodríguez
https://github.com/rubygems/rubygems/commit/0c3a65871a
2024-11-26[rubygems/rubygems] More aggressive `Performance/FlatMap` cop configurationDavid Rodríguez
https://github.com/rubygems/rubygems/commit/d8d68cc00e
2024-10-16[rubygems/rubygems] Delay and refactor verification of changed sourcesDavid Rodríguez
https://github.com/rubygems/rubygems/commit/d5dce93167
2024-08-22[rubygems/rubygems] Fix `--prefer-local` flagDavid Rodríguez
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 <[email protected]>
2024-07-09[rubygems/rubygems] Fix generic platform gems getting incorrectly removed ↵David Rodríguez
when locked for a specific platform If they are already in the lockfile as the most specific variant for a platform, we shouldn't change that unless explicitly unlocking. https://github.com/rubygems/rubygems/commit/a901660498
2024-07-09[rubygems/rubygems] Resolve all platforms directlyDavid Rodríguez
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
2024-07-09[rubygems/rubygems] Don't memoize sorted_spec_namesDavid Rodríguez
It's just for debugging and a simple method, so no need. https://github.com/rubygems/rubygems/commit/3230425a9a
2024-07-09[rubygems/rubygems] Instantiate `Resolver::SpecGroup` with explicit priorityDavid Rodríguez
https://github.com/rubygems/rubygems/commit/e2c1bc1b6c
2024-04-01[rubygems/rubygems] Fix typoDavid Rodriguez
https://github.com/rubygems/rubygems/commit/0ddf25e5aa
2023-12-07[rubygems/rubygems] Use modern hashes consistentlyDavid Rodríguez
https://github.com/rubygems/rubygems/commit/bb66253f2c
2023-11-13[rubygems/rubygems] Extract builder to create a `LazySpecification` from ↵David Rodríguez
full spec https://github.com/rubygems/rubygems/commit/957d3d9a7f
2023-11-13[rubygems/rubygems] Allow setting metadata on LazySpecificationDavid Rodríguez
This is a step forward towards eventually including metadata in the lockfile. https://github.com/rubygems/rubygems/commit/56fc02b251
2023-11-13[rubygems/rubygems] Set LazySpecification dependencies directlyDavid Rodríguez
https://github.com/rubygems/rubygems/commit/2462c8e04d
2023-10-16[rubygems/rubygems] Raise an error when top level dependency does not ↵David Rodríguez
resolve under all locked platforms https://github.com/rubygems/rubygems/commit/25304f3e8d
2023-04-06[rubygems/rubygems] Fix resolver hangs when dealing with an incomplete lockfileDavid Rodríguez
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
2023-04-06Revert "Refactor incomplete specs handling"David Rodríguez
This reverts commit 69580f8b72f41c58cae57d1ada4db909922b3891.
2023-03-28[rubygems/rubygems] Fix unnecessary downgrade of top level dependency when ↵David Rodríguez
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
2023-03-23Refactor incomplete specs handlingDavid Rodríguez
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
2023-01-31Merge RubyGems/Bundler master.Hiroshi SHIBATA
Pick from https://github.com/rubygems/rubygems/commit/5ace20dbecfeaf09fba5f616193f3cfcff70ba00 Notes: Merged: https://github.com/ruby/ruby/pull/7203
2023-01-10Merge RubyGems and Bundler masterHiroshi SHIBATA
from https://github.com/rubygems/rubygems/commit/0635c1423db5d7c461d53bf0c3329bca75de7609 Notes: Merged: https://github.com/ruby/ruby/pull/7094
2022-12-09Merge RubyGems/Bundler masterHiroshi SHIBATA
Pick from https://github.com/rubygems/rubygems/commit/823c776d951f3c35094611473ec77f94e8bf6610 Notes: Merged: https://github.com/ruby/ruby/pull/6890
2022-11-12Migrate our resolver engine to PubGrubHiroshi SHIBATA
https://github.com/rubygems/rubygems/pull/5960 Co-authored-by: David Rodríguez <[email protected]>
2022-10-18Merge RubyGems/Bundler masterHiroshi SHIBATA
https://github.com/rubygems/rubygems/commit/6214d00b2315ed37c76b1fbc1c72f61f92ba5a65 Notes: Merged: https://github.com/ruby/ruby/pull/6578
2022-10-18[rubygems/rubygems] Simplify fetching spec group dependenciesDavid Rodríguez
https://github.com/rubygems/rubygems/commit/62c2edd255 Notes: Merged: https://github.com/ruby/ruby/pull/6578
2022-10-18[rubygems/rubygems] Simplify SpecGroup creationDavid Rodríguez
https://github.com/rubygems/rubygems/commit/788e46e152 Notes: Merged: https://github.com/ruby/ruby/pull/6578
2022-09-05Merge ↵Hiroshi SHIBATA
https://github.com/rubygems/rubygems/commit/16c3535413afebcdbab7582c6017c27b5da8a8dc Notes: Merged: https://github.com/ruby/ruby/pull/6326
2022-08-23Merge rubygems/bundler HEADHiroshi SHIBATA
Pick from https://github.com/rubygems/rubygems/commit/6b3a5a9ab0453463381a8164efb6298ea9eb776f Notes: Merged: https://github.com/ruby/ruby/pull/6268
2022-08-23[rubygems/rubygems] Refactor building metadata dependenciesDavid Rodríguez
https://github.com/rubygems/rubygems/commit/fa60f1fe43 Notes: Merged: https://github.com/ruby/ruby/pull/6268
2022-07-13Merge RubyGems and Bundler masterHiroshi SHIBATA
Notes: Merged: https://github.com/ruby/ruby/pull/6124
2022-04-28Merge ↵Hiroshi SHIBATA
https://github.com/rubygems/rubygems/commit/3f7d0352e84b29d4a2d4cd93b31e5ebdb5f79cc6 Notes: Merged: https://github.com/ruby/ruby/pull/5669
2022-01-19Merge rubygems/rubygems HEAD.Hiroshi SHIBATA
Picked at 12aeef6ba9a3be0022be9934c1a3e4c46a03ed3a Notes: Merged: https://github.com/ruby/ruby/pull/5462
2021-05-11Sync bundler & rubygemsDavid Rodríguez
Notes: Merged: https://github.com/ruby/ruby/pull/4367
2021-03-08Sync latest development version of bundler & rubygemsDavid Rodríguez
Notes: Merged: https://github.com/ruby/ruby/pull/4143
2020-12-23Merge RubyGems 3.2.3 and Bundler 2.2.3Hiroshi SHIBATA
Notes: Merged: https://github.com/ruby/ruby/pull/3982
2020-12-15Prepare to release rubygems-3.2.1 and bundler-2.2.1Hiroshi SHIBATA
Notes: Merged: https://github.com/ruby/ruby/pull/3901
2020-10-15Merge bundler-2.2.0.rc.2Hiroshi SHIBATA
Notes: Merged: https://github.com/ruby/ruby/pull/3659
2020-05-13Update the bundler version with master branchHiroshi SHIBATA
Notes: Merged: https://github.com/ruby/ruby/pull/3086
2019-08-30Add guard as same as `==`Kazuhiro NISHIYAMA
Try to fix failure at https://github.com/ruby/ruby/runs/207580232#step:10:382 ``` undefined method `name' for "Gemfile.lock":String /home/runner/work/ruby/ruby/lib/bundler/resolver/spec_group.rb:65:in `eql?' ```
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-14 08:33:06 +0000