Support Golang Workspaces in Gazelle

[Kruemelmann]

Like mentioned in this issue in the rules_go repository, here is the issue in the gazelle repository.

My question is when Gazelle will support Golang workspaces or more precisely when it will be possible to use go.work files with gazelle.

[fmeum]

Relevant slack thread: https://bazelbuild.slack.com/archives/C014RARENH0/p1704836682274409?thread_ts=1700623974.089569&cid=C014RARENH0

[lstanden]

This is supposedly already supported:
#1250

[lstanden]

Not sure if this is the issue you're reporting, but I'll share what I just got working. Bazel Version 7.0.0rc1 (if that matters).

# MODULE.bazel

bazel_dep(name = "gazelle", version = "0.35.0", repo_name = "bazel_gazelle")
bazel_dep(name = "rules_go", version = "0.44.2", repo_name = "io_bazel_rules_go")
# (etc)

then

# BUILD.bazel
load("@bazel_gazelle//:def.bzl", "gazelle")


gazelle(
    name = "gazelle-update-repos",
    args = [
        "-from_file=go.work",
        "-to_macro=go_deps.bzl%go_deps",
        "-prune=True",
    ],
    command = "update-repos",
)

This is the only part that feels suboptimal:

# WORKSPACE.bazel

load("//:go_deps.bzl", "go_deps")

go_deps()

[stefanpenner]

I've been exploring and prototyping go.work via bzlmod over here. We are using this approach as a prototype at work, and it's working without issue.

Example in a tiny OSS go.work repo
https://github.com/stefanpenner/_bzlmod_go_work/blob/4c5ea1e6fd083ff20ada293056407bdf0919b55d/MODULE.bazel#L18-L19

A nice part of this, is no gazelle-update-repos is required.

One known caveat: all go dependencies in the workspace are visible to all go modules, even if a given module does not include it in its go.mod file. If users diligently run go mod tidy, no issues will arise, but if they do not, they may end up in a scenario where a build would pass with bazel but fail with native tooling. This would be a problem if the intent is for someone to consume the module in question as an external dependency.

On a positive note, their IDE should also tell them the problem exists. But CI would pass, and it really shouldn't.

@fmeum gave some suggestions, and I hope to explore them shortly.

• use visibility to emulate dependency scoping
• use gazelle to ensure

@sluongng also gave some suggestions with regards to avoiding relying on go.work.sum which I hope to also explore

[stefanpenner]

use visibility to emulate dependency scoping

I explored this, and although possible it seems a little funky, and I would love input:

• calculate the inter go module visibility graph
• ensure each go module is represented by a single package_group, lets say @repo/package-name:package_group. This helps simplify the values we place into visibility attributes.
• target visibility attrs within a given go module must include:
  • their own module package_group name (for interior visibility)
  • all dependent go module package_group names

use gazelle to ensure

I've started this, but haven't completed this exploration yet.

[lvoooo]

Relevant slack thread: https://bazelbuild.slack.com/archives/C014RARENH0/p1704836682274409?thread_ts=1700623974.089569&cid=C014RARENH0

Could you send me the invitation link of this slack? I can't find a usable one on the internet.

I'm currently using Bazel in my Go project and I may need some help to solve the problems.