go.work file support

[don-azlok]

https://github.com/bazelbuild/bazel-gazelle/blob/3a1235c298b7dc11fa7ba994db4f92587c1aca79/internal/bzlmod/go_deps.bzl#L447

[sluongng]

It's not impossible.

We need to rewrite https://github.com/bazelbuild/bazel-gazelle/blob/3a1235c298b7dc11fa7ba994db4f92587c1aca79/internal/bzlmod/go_mod.bzl to instead parsing go.mod and go.sum file as-is, to instead:

• execute go mod download -json
• parse the json outputs

Essentially recreating deps_from_go_mod and sum_from_go_mod with go.work

[malt3]

It's not impossible.

~Do you mean it is actually impossible? Or is it instead a lot of extra work?~ I think go.work OR support for multiple go.mod files would be great for large monorepos that also tend to use Bazel. Would the maintainers welcome support for correctly handling a go.work file for dependency management?

EDIT: oops.

[sluongng]

Not impossible == possible.

And yes it will require a decent amount of work to get it done. Probably not "a lot", but may be 1-2 weeks worth of effort from start until merged (very rough est).

[fmeum]

I haven't used Go workspaces yet, but if go.work really only consists of use and go directives, parsing it in Starlark may actually be easier than getting a Go SDK and running go mod download -json.

What I would like to see first is a clear specification of what supporting go.work actually means, considering that each Bazel module in the dependency graph could have its own go.work file and we have to reconcile those (or decide that only the root module should get to use this feature). It's also not clear to me whether supporting go.work would also require making Gazelle of all the Go modules in the workspace (e.g. to generate correct importpaths).

[malt3]

What I would like to see first is a clear specification of what supporting go.work actually means, considering that each Bazel module in the dependency graph could have its own go.work file and we have to reconcile those (or decide that only the root module should get to use this feature).

Go only allows one go.work file to be used and reconciling multiple sounds like it may lead to conflicts (multiple go.work files could try to replace the same module differently). I'm not sure if Bazel can represent this or if it makes sense to implement, but maybe a correct implementation would allow for multiple isolated dependency graphs. One for each go.work. A Bazel workspace could then use exactly one go.work file or one go.mod file. This ensures a label for a go_binary rule actually resolves to a concrete dependency graph.

It's also not clear to me whether supporting go.work would also require making Gazelle of all the Go modules in the workspace (e.g. to generate correct importpaths).

I think use directives in go.work are conceptually similar to replace directives with local paths in go.mod files. That probably means Gazelle has to be aware of all Go modules that are used in a go.work file. This way Gazelle could use the local module instead of generating labels for external repositories.