@fast-nail-55400 one awkward edge w/ Go Protobuf.

go mod tidy

will fail:

they might if they want to make the generated sources visible to their IDE

or run

go mod tidy

, right?

I've been trying to get generated Go protobufs to play nicely with IDEs and "non-Pants usage" as well (like

go mod tidy

) - it's tricky to say the least. A

replace

in

go.mod

pointing towards the result of

export-codegen

makes

go mod tidy

aware of the code at least, but then it complains about a missing

go.mod

in that export dir instead.

That's good to know that it's tricky outside of pants too… How much of a dealbreaker do you think this is Jonas? It sounds like there is a workaround, only very awkward

I think it's very user specific if it's a dealbreaker or not. Personally I could live with my IDE complaining about missing imports since in exchange I stop having generated Go code in the repository.

go mod tidy

(and possibly other commands) not working would be a bit more annoying though. But that's just me - I don't think I'd get away with migrating my work project's Go proto code to Pants without at least figuring out a workaround first. Having generated code in the repo isn't pretty, but at least everything works as my co-workers expects it to (except they keep forgetting to regenerate the Go code when they add things to the protobufs 🙈).

(Asked generally:) how does Bazel handle this?

Relevant issue for Bazel: https://github.com/bazelbuild/rules_go/issues/512 Sounds like Go has added some

GOPACKAGESDRIVER

environment variable that points to a binary that will read requests on its stdin, and output the Package struct as JSON on stdout. There's not too much documentation about it, but Bazel added some sort of support for it here. They also explain how it works in Bazel a bit more here.

Hey @narrow-vegetable-37489 - any luck with setting this up? I’m struggling to get something working in vscode myself

I ended up "solving" it by creating a symlink where Go expects the generated protobufs to be located that points to the relative path of the output of

export-codegen

. Pants is happy,

go mod

is happy, my IDE is happy, so good enough for me 🙂

Thanks so much! I was pulling my hair out over this 🙂

@narrow-vegetable-37489 could you post what the symlink looked like? i'm wrestling with making goland happy on this exact issue

Sorry, missed this! We’ve got all our Go code in

<repo root>/golang/

and our

go.mod

in that folder defines the root module as

module <http://git.example.com/group/project/golang|git.example.com/group/project/golang>

. Our protobufs are in

<repo root>/protobuf/

, and in each .proto file we set

package

and

go_package

. For

protobuf/foo/bar.proto

it’d be:

package foo;

option go_package = git.example.com/group/project/golang/protobuf/foo";

Then we’ve simply created a symlink in

golang

that points to the protobufs generated by

pants export-codegen

with

ln -s protobuf ../dist/codegen/protobuf

In Go we can then import the generated protobufs from

<http://git.example.com/group/project/golang/protobuf/foo|git.example.com/group/project/golang/protobuf/foo>

. It’s not perfect, but works good enough for the relatively little Go code we have.