search

bazel-contrib / bazel-gazelle

Gazelle is a Bazel build file generator for Bazel projects. It natively supports Go and protobuf, and it may be extended to support new languages and custom rule sets.
Apache License 2.0
1.19k stars 378 forks source link

rules_license is not visible from go_repository #1942

Closed archen closed 1 week ago

archen commented 2 weeks ago

What version of gazelle are you using?

0.39.0

What version of rules_go are you using?

0.50.1

What version of Bazel are you using?

7.3.1

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

Yes

What operating system and processor architecture are you using?

MacOS Sequoia Apple Silicon

What did you do?

I attempted to build a go_binary target with dependencies on external go modules.

What did you expect to see?

A successful build of my binary.

What did you see instead?

An error occurs citing that rules_license is not visible from any of the repositories generated by gazelle's go_repository rule(s).

ERROR: [redacted]/BUILD.bazel:3:11: error loading package '@@flow~~go_deps~com_github_google_uuid//': Unable to find package for @@[unknown repo 'rules_license' requested from @@flow~~go_deps~com_github_google_uuid]//rules:package_info.bzl: The repository '@@[unknown repo 'rules_license' requested from @@flow~~go_deps~com_github_google_uuid]' could not be resolved: No repository visible as '@rules_license' from repository '@@flow~~go_deps~com_github_google_uuid'. and referenced by '//:redacted-target'

This is not a problem in gazelle prior to 0.39.0, I have tested in 0.38.0 and 0.37.0.

It appears that the issue is introduced by https://github.com/bazelbuild/bazel-gazelle/blob/66d30923fb815166f10019059f915a64b659cebd/internal/go_repository.bzl#L401

Is there a configuration for bzlmod users that can help workaround the issue for 0.39.0?

fmeum commented 1 week ago

What's flow in@@flow~~go_deps~com_github_google_uuid? Is it possible that you are using the go_deps extension through some other module? That is not a supported use case precisely because Gazelle adding new deps would break you.

archen commented 1 week ago

We surely are: flow is an internal repository for our own bazel rules.

We also use it to maintain module versions for all of our projects in one place. Effectively, we re-export @bazel_gazelle//:extensions.bzl%go_deps (and others) as a member of a struct defined in flow. This helps us reduce module maintenance across repositories by introducing a handy abstraction layer; our developers update one version in their MODULE.bazel and are then using the latest and greatest of all of our dependencies.

I understand the unsupported use case stance, though I am surprised that this is the first and only dependency of ours that has presented the issue.

fmeum commented 1 week ago

I would heavily recommend using module file segments (via the include function) instead to avoid this.

This will happen often, but you will only notice it if some ruleset adds a new dep that is not a transitive dep of any other ruleset.

archen commented 1 week ago

thanks for the recommendation! for anyone else that stumbles on this thread: https://bazel.build/rules/lib/globals/module#include