Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Bazel module resolution regression in go_deps #1966

Merged
merged 2 commits into from
Oct 25, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion MODULE.bazel
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
module(
name = "gazelle",
# Updated by the Publish to BCR app.
version = "0.30.0",
version = "",
repo_name = "bazel_gazelle",
)

Expand Down
12 changes: 9 additions & 3 deletions internal/bzlmod/go_deps.bzl
Original file line number Diff line number Diff line change
Expand Up @@ -566,21 +566,27 @@ def _go_deps_impl(module_ctx):
if path in archive_overrides or path in gazelle_overrides or path in module_overrides or path in replace_map:
continue

# Only use the Bazel module if it is at least as high as the required Go module version.
if path in module_resolutions and bazel_dep.version != module_resolutions[path].version:
# Do not report version mismatches for overridden Bazel modules.
if path in module_resolutions and bazel_dep.version != _HIGHEST_VERSION_SENTINEL and bazel_dep.version != module_resolutions[path].version:
outdated_direct_dep_printer("\n\nMismatch between versions requested for module {module}\nBazel dependency version requested in MODULE.bazel: {bazel_dep_version}\nGo module version requested in go.mod: {go_module_version}\nPlease resolve this mismatch to prevent discrepancies between native Go and Bazel builds\n\n".format(
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it expected that this DEBUG print also happens when the dep in go.mod is indirect?

To give a concrete example, we have cel.dev/expr v0.18.0 // indirect in go.mod, and 0.15.0 in bazel mod graph which is a transitive dep of grpc-java shown as following, so neither of them is a direct dep.

├───grpc-java@1.67.1
   ├───cel-spec@0.15.0

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say that's desired behavior as it gives you the opportunity to explicitly add a replace directive for the version you'd like, if you so chose.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check makes sense. I was just wondering whether this function outdated_direct_dep_printer was designed for this purpose.

module = path,
bazel_dep_version = bazel_dep.raw_version,
go_module_version = module_resolutions[path].raw_version,
))

# Only use the Bazel module if it is at least as high as the required Go module version.
if path in module_resolutions and bazel_dep.version < module_resolutions[path].version:
continue

# TODO: We should update root_versions if the bazel_dep is a direct dependency of the root
# module. However, we currently don't have a way to determine that.
module_resolutions[path] = bazel_dep

for path, root_version in root_versions.items():
if semver.to_comparable(root_version) < module_resolutions[path].version:
resolved_version = module_resolutions[path].version

# Do not report version mismatches for overridden Bazel modules.
if resolved_version != _HIGHEST_VERSION_SENTINEL and semver.to_comparable(root_version) < resolved_version:
outdated_direct_dep_printer(
"For Go module \"{path}\", the root module requires module version v{root_version}, but got v{resolved_version} in the resolved dependency graph.".format(
path = path,
Expand Down