Fix package names for v1 protos, misc proto changes#24183
Conversation
codingllama
left a comment
There was a problem hiding this comment.
This is great, Edoardo. Thanks!
I'm surprised we didn't require any code changes, I suppose that means every single "v1" import was already aliased. That's good.
Maybe rename the PR to something more descriptive? Say, "Use named packages for all v1 protos" (or something else?).
|
Could we have backports too, if it's not too much trouble? Having the named packages is good if people rely on them, plus uniform codegen among release branches is nice. I'll tentatively add the labels, see what you make of it in practice. |
|
I have the v12 backport ready but it's based on #24196; the other ones I can do, but I question the need for v10, since v13 is right around the corner. |
Had a quick look, approved. That should make it easier. ;)
Sure, that's fair. Your call. |
This also adds protoc-gen-go-grpc to go.mod
…24266) * Delete teleterm's ptyHost/v1, added by mistake * Add package name to protos conforming to PACKAGE_VERSION_SUFFIX * use go run in buf-connect-go.gen.yaml directly * Run protogen in place, go run in buf-go This drops the dependency on some random v1.4.3 version of the legacy protoc-gen-go for teleterm protos, using the version in the main go.mod instead.
…24263) * Delete teleterm's ptyHost/v1, added by mistake * Add package name to protos conforming to PACKAGE_VERSION_SUFFIX * use go run in buf-connect-go.gen.yaml directly * Run protogen in place * Run the buf-go generation off of go run This also adds protoc-gen-go-grpc to go.mod * go mod tidy
This PR:
foov1rather than picking some random name for them;go runs protoc-gen-go and protoc-gen-go-connect directly from buf rather than via a shell script;github.com, as much as possible (gogoproto can't do that, so we still generate in a subdirectory and then copy the output out);