Skip to content

Conversation

@meteorcloudy
Copy link
Member

Previously, nodep edges were simply ignored during version selection, even if "fulfilled" (as in, another version of the dependency exists somewhere else in the graph). Their effect was only visible because they made more modules show up in the unresolved dependency graph, causing MVS to pick them up. But this meant that when max_compatibility_level was involved, we might get surprising results.

Now we also take fulfilled nodep edges into account during version selection. Most importantly, the post-selection graph walk now takes nodep edges into account, meaning that any existing max_compatibility_level dep is forced to upgrade to ensure that only one version remains in the final graph.

Fixes #27441.

PiperOrigin-RevId: 826401269
Change-Id: I2a0970b409adfe0b42456a54dbd626fc63a1523a

Also backported e327c1b

Closes #27477

fmeum and others added 3 commits October 31, 2025 11:27
* Enforce via the type system that a resolution strategy can't change the module name.
* Use a wither instead of the constructor to avoid losing information when changing the version of a `DepSpec`.

This will be used as a base for simplifications to the selection algorithm, whose runtime is currently exponential in the number of deps with non-trivial `max_compatibility_level`.

Along the way, fix an error message and add test cases.

Closes bazelbuild#26573.

PiperOrigin-RevId: 797428276
Change-Id: I1a3020ae14172140ce59332cbac79ea18fad1a86
Previously, nodep edges were simply ignored during version selection, even if "fulfilled" (as in, another version of the dependency exists somewhere else in the graph). Their effect was only visible because they made more modules show up in the unresolved dependency graph, causing MVS to pick them up. But this meant that when `max_compatibility_level` was involved, we might get surprising results.

Now we also take fulfilled nodep edges into account during version selection. Most importantly, the post-selection graph walk now takes nodep edges into account, meaning that any existing `max_compatibility_level` dep is forced to upgrade to ensure that only one version remains in the final graph.

Fixes bazelbuild#27441.

PiperOrigin-RevId: 826401269
Change-Id: I2a0970b409adfe0b42456a54dbd626fc63a1523a
@meteorcloudy meteorcloudy requested a review from a team as a code owner October 31, 2025 10:48
@meteorcloudy meteorcloudy requested review from Wyverald and removed request for a team October 31, 2025 10:48
@github-actions github-actions bot added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. awaiting-review PR is awaiting review from an assigned reviewer labels Oct 31, 2025
@meteorcloudy meteorcloudy added this pull request to the merge queue Oct 31, 2025
Merged via the queue into bazelbuild:release-8.5.0 with commit 170892f Oct 31, 2025
47 checks passed
@github-actions github-actions bot removed the awaiting-review PR is awaiting review from an assigned reviewer label Oct 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants