https://pantsbuild.org/ logo
#general
Title
# general
g

gifted-autumn-61196

05/09/2023, 8:53 PM
Hi, just bringing up a golang question that i had a couple weeks ago again. I did find this 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?
w

witty-crayon-22786

05/09/2023, 9:15 PM
as far as i’m aware of,
go.work
files are not yet supported (if that’s what you’re referring to?)
f

fast-nail-55400

05/10/2023, 4:56 PM
I believe @gifted-autumn-61196 is referring to support for the
go.mod
replace
directive with a local path replacement.
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.
Changing that assumption is what would require work (and of course testing).
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.
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).
g

gifted-autumn-61196

05/10/2023, 8:36 PM
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?
f

fast-nail-55400

05/10/2023, 8:46 PM
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.
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.
the issue is that no one is actively working on the go backend in Pants
so while it would be nice to solve it, unless someone puts the development effort in, it won't get solved