search

bazelbuild / rules_go

Go rules for Bazel
Apache License 2.0
1.37k stars 651 forks source link

rules_go 0.48.0 inconsistent strict deps behavior between bzlmod enabled and disabled #3953

Closed ted-xie closed 3 months ago

ted-xie commented 3 months ago

What version of rules_go are you using?

0.48.0

What version of gazelle are you using?

0.28.0

What version of Bazel are you using?

7.2.0rc2

Does this issue reproduce with the latest releases of all the above?

Yes.

What operating system and processor architecture are you using?

Debian Linux derivative; x86-64

Any other potentially useful information about your toolchain?

N/A

What did you do?

git clone git@github.com:ted-xie/rules_android -b golang_cleanups
cd rules_android
USE_BAZEL_VERSION=7.2.0rc2
bazelisk build src/tools/ak/extractresources:extractresources --enable_bzlmod
bazelisk build src/tools/ak/extractresources:extractresources --noenable_bzlmod

What did you expect to see?

I expected both invocations to behave identically; either both pass or both fail.

What did you see instead?

The --enable_bzlmod command succeeds, but the --noenable_bzlmod command fails.

compilepkg: missing strict dependencies:
        /usr/local/google/home/tedx/.cache/bazel/_bazel_tedx/1c2a5f93603eac914aee368bc6431057/sandbox/linux-sandbox/2/execroot/rules_android/src/tools/ak/extractresources/extractresources.go: import of "slices"
No dependencies were provided.
Check that imports in Go sources match importpath attributes in deps.

Looking deeper at the failed commands, I see that the bzlmod run has a fully-populated packages.txt for the context for its GoCompilePkg mnemonic. That packages.txt contains slices. Looking at the packages.txt for the non-bzlmod run, it seems to have a similar list of packages, but slices is conspicuously missing.

ted-xie commented 3 months ago

One other note: This is currently breaking BazelCI for rules_android.

ted-xie commented 3 months ago

OK, I think I found a workaround for this. It turns out that my go sdk version in WORKSPACE was too old somehow (was 1.20.5; bumping to 1.22.4 helped). I also had not set the SDK version properly in MODULE.bazel, so I think what happened was that the bzlmod invocation was pulling a sufficiently modern SDK, while the WORKSPACE invocation was locked to an older one.