Hi just bringing up a golang question that i had a couple we

Question

Hi just bringing up a golang question that i had a couple weeks ago again I did find this <https pantsbuild slack com archives C046T6T9U p1672773322439959|conversation> about this same issue and was wondering if anything has changed since then Specifically about consuming local versions of golang modules instead of doing tagged releases and consuming them as 3rd parties If it hasn t is there an estimate to how much effort it would be to add this capability

witty-crayon-22786 · Answer

as far as i m aware of `go work` files are not yet supported if that s what you re referring to

fast-nail-55400 · Answer

I believe < gifted autumn 61196> is referring to support for the `go mod` `replace` directive with a local path replacement

fast-nail-55400 · Answer

It probably would require a fair amount of work to implement The go backend currently treats each `go mod` target and related packages as its own separate entity in a similar manner to resolves in Python and JVM

fast-nail-55400 · Answer

Changing that assumption is what would require work and of course testing

fast-nail-55400 · Answer

There is some precedent in the current code base for allowing a single package to exist in multiple `go mod` resolves The protobuf target has a `go mod address` field which can be used with the `paramarize` built in much how it works for the `resolve` field

fast-nail-55400 · Answer

But `go package` does not currently have a `go mod address` field so that technique has no way to work and would need lots of testing in any event

gifted-autumn-61196 · Answer

bazel just ignores the replace directive and everything still works since the dependency on the local files are explicit in the `dependency` field i m assuming that if i remove the replace from the go mod and add a dependency myself it will still fail

fast-nail-55400 · Answer

bazel also doesn t deal with `go mod` files directly gazelle is generally used to maintain the `BUILD bazel` files based on them but `rules go` doesn t know about `go mod` files

fast-nail-55400 · Answer

whereas for Pants the original intent was to match the `go` toolchain a little closer than Bazel does although it isn t the same in places as you have encountered

fast-nail-55400 · Answer

the issue is that no one is actively working on the go backend in Pants

fast-nail-55400 · Answer

so while it would be nice to solve it unless someone puts the development effort in it won t get solved