option for protoc-gen-connect-go to output to same package as protoc-gen-go

[frantjc]

I had a use-case where I wanted .connect.go files generated with protoc-gen-connect-go to output to the same directory as .pb.go files generated with protoc-gen-go.

The reason I needed this was to preserve import paths when switching from Go structs that I'd written myself with ones generated from .proto files. The same package previously referenced Service Clients generated by protoc-gen-grpc-go which, when extracted to the ___connect package that protoc-gen-connect-go outputs to, caused an import cycle.

I forked and modified proton-gen-connect-go to never append the ___connect part to the import path and I would like to contribute it back upstream. However, I was hoping for some direction on what flag I should check to disable appending ___connect to the import path: an environment variable? A flag passed to protoc-gen-connect-go? Something else entirely?

Hope that was clearly articulated. Thanks!

[akshayjshah]

Thanks for proposing this, @frantjc! We've gone back and forth on this, most recently in #70.

We'd rather not do this because it makes it hard to move away from local code generation. With the current approach, you can go get go.buf.build/bufbuild/connect-go/your-org/your-schema - no local buf or protoc invocation needed, because the Buf Schema Registry knows that it only needs to run protoc-gen-connect-go. At Buf, we think that making it easier to consume generated code is critical to 10x-ing protobuf usage. As soon as multiple plugins are generating code into the same package, this becomes impossible.

That said, we're willing to add an option if there's significant interest. I'm going to convert this issue to a discussion and wait a bit to see if it accumulates a bunch of upvotes or comments.

[lbensaad]

@frantjc , I did not know you asked the same thing I need (#389).
In my opinion, connect should follow the flag --connect-go_out passed to protoc and just put the generated file in the folder specified by that flag. For the package name it should also take it from the .proto file. In my opinion, this behavior of adding a suffix to the package and putting it in other folder is breaking protobuf specs.

@akshayjshah I hope you put this behavior behind a flag, for example usePkgSuffix, and give us the possibility to disable or enable this behavior.

I wanted to switch from grpc-go but the way how connect structures code made several breaking changes in my code structure. Because I structure my code trying to flow clear architecture, where each feature has the folders: app, data, domain, and port. The folder port contains all my grpc and pb code, but when I use connect it adds another folder named portconnect that will contain only one file. When I import the portconnect package in the port package it causes an import cycle error, because the port package contains the .pb.go file which is imported by portconnect

[bufdev]

If we can come up with clear design, I'm not 100% against adding an option for this. We may want to consider what the shape of the option is exactly, i.e. do we want something like package={suffix,same,whatever} or same_package=true, or something else.

One note:

In my opinion, this behavior of adding a suffix to the package and putting it in other folder is breaking protobuf specs.

Just to be sure we're on the same page: is no Protobuf spec here, Protobuf does not define anything with regards to the outputted stubs. The choice to output i.e. grpc-go code to the same package as golang/protobuf code was a choice (and in our opinion, the wrong one), just as generating to a separate package is a choice. In our view, you should not tie a specific RPC framework's generated stubs to the same package as the base types. In theory, you should be able to have i.e. Twirp, gRPC, and Connect generated code all happy generate within the same repository and use the same interface names for Client and Server stubs, which you cannot do if they all generate to the same package. Similarly, I should not need to import i.e. google.golang.org/grpc if I am using github.com/bufbuild/connect-go, which would be the case if both grpc-go and connect-go stubs were generated to the same package as the base types.

[frantjc]

I agree with connect's design choice to generate a new package, it can just lead to problems when migrating from gRPC to connect due to gRPC's differing design choice.

I am, however, still a proponent for an option to modify this behavior, as more functionality can't really hurt, whatever shape it may take! :)

[lbensaad]

Thank you all. I have successfully replaced grpc-go and I am using connect-go, and now I understand you. I like its simplicity and the concept of directly using net/http 😍.
So no need for this feature and I am down-voting it.
I am also ditching grpc-go and grpc-web and down-voting them as well 😌