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.21k
stars
381
forks
source link
gazelle does not rewrite build files from vendored go code #1982
...
bazel_dep(name = "rules_go", version = "0.50.1")
...
And after go mod vendor, bazel run //:gazelle -- fix also left those build files untouched (it generates build files for vendored directories lacking them, but not change them if they already exists), resulting in the code won't build because io_bazel_rules_go cannot be resolved.
Currently we just run buildozer after bazel run //:gazelle -- fix:
What version of gazelle are you using?
0.40.0
What version of rules_go are you using?
0.50.1
What version of Bazel are you using?
7.4.1
Does this issue reproduce with the latest releases of all the above?
Those are latest releases
What operating system and processor architecture are you using?
linux/amd64
What did you do?
As mitigation to #1977, we start to vendor via
go mod vendor
.go mod vendor
keeps build files from go dependencies if they exist. Some of our go dependencies (github.com/grpc-ecosystem/grpc-gateway & github.com/google/flatbuffers) have build files usingio_bazel_rules_go
. For example: https://github.com/grpc-ecosystem/grpc-gateway/blob/195cb0fb4abb13a20b42dc97dd754fc81e28b63d/utilities/BUILD.bazel#L1.We use
rules_go
as the name in ourMODULE.bazel
:And after
go mod vendor
,bazel run //:gazelle -- fix
also left those build files untouched (it generates build files for vendored directories lacking them, but not change them if they already exists), resulting in the code won't build becauseio_bazel_rules_go
cannot be resolved.Currently we just run buildozer after
bazel run //:gazelle -- fix
:But it would be great if gazelle can (provide an option to) fix them so we don't have to use buildozer.
What did you expect to see?
What did you see instead?