grpc-go: undefined: grpc.SupportPackageIsVersion3
The following commit:
commit 727a60e4d135c53c4d62d708ac4528f7c077c0d0
Author: Mak Mukhi <mmukhi@google.com>
Date: Fri Oct 21 18:06:55 2016 -0700
update server reflection code to comply with the change to the grpc generator
Introduces the error:
# github.com/org/repo/vendor/some_grpc_lib
vendor/some_grpc_lib/some_lib.pb.go:173: undefined: grpc.SupportPackageIsVersion3`
The error message is not helpful. I have tried regenerating source files using the latest protoc
$ protoc --version
libprotoc 3.1.0
How can this problem be fixed? Can you provide a more helpful error message?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 26 (9 by maintainers)
We are having a nightmare of a time dealing with this issue also.
How do you recommend working through it?
Here’s an example. We have a developer working on project A who generates their gRPC code with
grpc.SupportPackageIsVersion3.A developer working on project B imports the package with the generated gRPC client from project A. Project B also needs to generate a gRPC server but they generate it with
grpc.SupportPackageIsVersion4.Now the project cannot build.
So you suggest re-generating the protofile from Project A, but this feels weird to us. Now we’re changing a vendored file (the generated file) that really should be untouchable since it belongs to Project A.
Also, a lot of our files are difficult to generate in the vendored folder since they rely on imports that are relative to Project’s A repo.
Another alternative is to copy/paste the code in the .proto file from Project A to Project B and have Project B generate its own client code. We’re duplicating that code and separating it though, so this seems less than ideal as well.
What do you suggest? This really is a huge problem for us and I don’t feel like there’s a great solution. If you have a single gRPC dependency you are importing then it might be fairly straight-forward, but when you have several that each have several dependencies of their own it becomes a huge pain.
This is not rocket science. We simply add a variable grpc.SupportPackageIsVersionX (X is the integer and the current value is 4) to make sure your grpc lib and the generated code work on the same version. We think this is a nice feature so that our users won’t blindly mess up different version altogether which may have undefined errors and hard to tackle. In general, if you encounter this problem, check this file (https://github.com/golang/protobuf/blob/master/protoc-gen-go/grpc/grpc.go#L51) and this file (https://github.com/grpc/grpc-go/blob/master/rpc_util.go#L481) for both your project and its dependencies (if they also use gRPC) and see whether they are matched. If they are not, update the repo to make them consistent (you probably need to do additional steps if this happens to your dependencies. I do not want to recommend a way here because this highly depends on your best practice.). Once they are consistent, regenerate all the code. The problem should go away.
@troylelandshields Yes it is a huge pain if your project has a deep dependency tree. But this pain is not specific to grpc. Basically it applies to all the libraries which are used in multiple places in the dependency tree. I think the library should ship with its vendored grpc library, which makes the life much easier.
@iamqizhao thank you for reminding me that it’s not rocket science.
My point is simply that other non-rocket-scientist people are going to run into this issue as gRPC and Go increase in popularity. They are going to be coming here to look for answers or ask for help as well.
Obviously a lot of thought was put into the decision to add this feature so I think it was fair to assume that we were doing something wrong and you guys must have had a best practice in mind for dealing with this. Apparently the best practice is “deal with it,” which is pretty unsatisfactory but we’ll figure it out.
You need to be like Google and work out of one giant repo for all projects… :troll:
@MakMukhi I just moved aside my entire $GOPATH, reinstalled from scratch, and am getting the same error. Can you not reproduce? Does this show that the issue is not on my end, but rather upstream? Anything else I should try?
I guess your vendored gRPC is outdated. And did you try to regenerate the file you mentioned
vendor/some_grpc_lib/some_lib.pb.go?