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

Hi, just bringing up a golang question that i had ...

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?

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?)

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.

fast-nail-55400

05/10/2023, 4:58 PM

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

05/10/2023, 4:58 PM

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

fast-nail-55400

05/10/2023, 5:00 PM

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

05/10/2023, 5:03 PM

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

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?

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.

fast-nail-55400

05/10/2023, 8:48 PM

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

05/10/2023, 8:49 PM

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

fast-nail-55400

05/10/2023, 8:49 PM

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

Open in Slack

Previous Next