-
Tom van der Woerdt authored
* go_repository: add 'clean' build_file_generation Before bzlmod, repositories were global, and BUILD files inside upstream repositories could load from the repositories defined at the root-level WORKSPACE file. With the introduction of visibility rules, these result in errors that cannot trivially be worked around. One pattern that has emerged is ignoring existing build files by specifying `gazelle:build_file_name BUILD.bazel`, however this does not work for anything already using BUILD.bazel filenames. This does affect real-world users: an example is github.com/google/go-jsonnet which has a BUILD.bazel file to `genrule` its AST. The module is pure-go, but the build step contains cpp code, and when imported under bzlmod-gazelle will not work because the cpp code is invoked. As a workaround, there is now a 'jsonnet' BCR module. This patch introduces a `build_file_generation = clean` option, which removes existing build files before generating new ones. It allows loading the jsonnet code once again, and also makes it possible to load some of the complex protobuf repositories. * go_repository: always call fetch_repo, even for urls After my changes to remove build files as part of fetch_repo, I realized that when urls=[] is specified the code path doesn't use fetch_repo at all. In this case, fetch_repo_args would remain None, and raise an error. Not ideal! This left me with two general options: either I move the code into a separate command invocation, or I have all code go through fetch_repo. The latter seems to be the pragmatic solution: gazelle by itself doesn't generate code with urls=[] (in either bzlmod or vanilla update-repos), so it's the option with lower performance impact (also considering we're stacking it on top of a network download).