Description of the bug:
When the .bzl files transitively loaded by a module extension don't change, but their repo mapping does, a module extension locked in the lockfile can return stale results.
Which category does this issue belong to?
External Dependency
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
# MODULE.bazel
bazel_dep(name = "rules_go", version = "0.40.0")
ext = use_extension("//:ext.bzl", "ext")
ext.tag(label_str = "@rules_go//go")
use_repo(ext, "repo")
other_ext = use_extension("//:other_ext.bzl", "other_ext")
use_repo(other_ext, "other_repo")
# BUILD
load("@repo//:defs.bzl", "LABEL")
load("@other_repo//:defs.bzl", "STR")
print(LABEL)
print(STR)
# ext.bzl
def _repo_impl(ctx):
ctx.file("WORKSPACE")
ctx.file("BUILD")
ctx.file("defs.bzl", "LABEL = Label({})".format(repr(ctx.attr.label_str)))
_repo = repository_rule(
implementation=_repo_impl,
attrs={"label_str": attr.string(mandatory=True)},
)
_tag = tag_class(
attrs={"label_str": attr.string(mandatory=True)},
)
def _ext_impl(ctx):
for module in ctx.modules:
for tag in module.tags.tag:
_repo(name = "repo", label_str = tag.label_str)
ext = module_extension(
implementation=_ext_impl,
tag_classes={"tag": _tag},
)
# other_ext.bzl
load("@repo//:defs.bzl", "LABEL")
def _other_repo_impl(ctx):
ctx.file("WORKSPACE")
ctx.file("BUILD")
ctx.file("defs.bzl", "STR = {}".format(repr(ctx.attr.str)))
_other_repo = repository_rule(
implementation = _other_repo_impl,
attrs = {
"str": attr.string(),
},
)
def _other_ext_impl(_):
_other_repo(name = "other_repo", str = str(LABEL))
other_ext = module_extension(
implementation = _other_ext_impl,
)
$ bazel build //...
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:3:6: @@rules_go~0.40.0//go:go
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:4:6: @@rules_go~0.40.0//go:go
$ buildozer 'set version 0.41.0' MODULE.bazel:rules_go
$ bazel build //...
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:3:6: @@rules_go~0.41.0//go:go
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:4:6: @@rules_go~0.40.0//go:go
$ bazel build //... --lockfile_mode=off
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:3:6: @@rules_go~0.41.0//go:go
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:4:6: @@rules_go~0.41.0//go:go
$ buildozer 'set version 0.40.0' MODULE.bazel:rules_go
$ bazel build //... --lockfile_mode=off
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:3:6: @@rules_go~0.40.0//go:go
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:4:6: @@rules_go~0.40.0//go:go
Which operating system are you running Bazel on?
No response
What is the output of bazel info release?
7.0.0 and HEAD
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?
No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
This is a regression in 7.0.0 since the lockfile is now enabled by default.
Have you found anything relevant by searching the web?
The reproducer is a synthetic, simplified version of the original problem (https://bazelbuild.slack.com/archives/CDBP88Z0D/p1703062323776219), which affects rules_go.
Any other information, logs, or outputs that you want to share?
No response
Description of the bug:
When the
.bzlfiles transitively loaded by a module extension don't change, but their repo mapping does, a module extension locked in the lockfile can return stale results.Which category does this issue belong to?
External Dependency
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Which operating system are you running Bazel on?
No response
What is the output of
bazel info release?7.0.0 and HEAD
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
This is a regression in 7.0.0 since the lockfile is now enabled by default.
Have you found anything relevant by searching the web?
The reproducer is a synthetic, simplified version of the original problem (https://bazelbuild.slack.com/archives/CDBP88Z0D/p1703062323776219), which affects rules_go.
Any other information, logs, or outputs that you want to share?
No response