bzlmod support

[hochhaus]

Does nogo-analyzer support bzlmod? If so, could a section be added to the documentation stating how to set it up?

[sluongng]

Not yet. I probably won’t have the bandwidth to work on it for several months.

I could help review such contribution though.

[sluongng]

I had a chance to take a quick look at this problem I was preparing for v0.0.3 release and tbh, it's not yet clear to me how to solve it.

The problem is that today, I am managing the dependencies in this repo with go.work and multiple go.mod files inside that workspace. This allows me to create smaller deps.bzl for downstream users to only include what they need.

For example, if you only use //staticcheck portion of the repo, you will not need to import everything in //golangci-lint:deps.bzl.

This, however, is hard to do with bzlmod.

First of all, you would need to switch the dependencies management over to gazelle.go_deps extension, which is a monolithic approach leveraging the current Go module system. So that would require me to include a bunch of dummy.go into different packages to expose the upstream dependencies to downstream users. A bit yuck, but ok.

Secondly, when users import nogo-analyzer dummy packages as tool dependencies via go get, that would subject nogo-analyzer to Gazelle's go_repository build file generation, which lack the extension we need. 🤔

Lastly, if the BUILD files are overridden, then we will face a problem similar to bazelbuild/bazel#19301, which is still a blocker.

I briefly considered rolling my own bzlmod extensions to generate the go_repository myself. But it could be quite some complexity to maintain and it's unclear how the conflict with Gazelle's go_deps would be resolved.

So I think I will wait a bit longer to implement Bzlmod support for nogo-analyzer. Folks could still use the repo today with WORKSPACE.bzlmod file.

And if any contributors is willing to work on bzlmod support, I could give the PR a review.

[sluongng]

With the latest version of Bazel, you can just do this

http_archive = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "com_github_sluongng_nogo_analyzer",
    sha256 = "a74a5e44751d292d17bd879e5aa8b40baa94b5dc2f043df1e3acbb3e23ead073",
    strip_prefix = "nogo-analyzer-0.0.2",
    urls = [
        "https://github.com/sluongng/nogo-analyzer/archive/refs/tags/v0.0.2.tar.gz",
    ],
)

All of the go deps could be managed with go mod like this https://github.com/buildbuddy-io/buildbuddy/blob/a27cf50f3b8d9722e442c6dc1de281bd9ea500fb/tools/deps/deps.go#L26-L29.

So I don't think we need additional support for Bzlmod in the repo.

This issue could be closed with a simple document update.

[ob]

I'm not sure it's that simple. If I do that none of the dependencies are resolved correctly (e.g. nogo_analyzer uses @io_bazel_rules_go which isn't loaded and the bazel_dep() I have exposes it as rules_go). There's others as well.

[sluongng]

I think you can use something like this

bazel_dep(name = "rules_go", version = "0.50.1", repo_name = "io_bazel_rules_go")

to work around the repo name issue. We probably want to stay on io_bazel_rules_go for a while longer to give WORKSPACE folks an easier time. I think Bazel 9 would be a sweet timeline to migrate over to the new rules_go name.

[ob]

Yeah, that's a workaround but you need to use it for each conflicting name and it also gets exposed to your own project.