Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go get -u github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway fails on clean environment #731

Closed
Makman2 opened this issue Aug 17, 2018 · 21 comments

Comments

@Makman2
Copy link

Makman2 commented Aug 17, 2018

Steps you follow to reproduce the error:

  1. Move into a clean environment: docker run -it golang:1.10.3 bash
  2. Run go get -u github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway

That fails with an error:

# github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway/descriptor
src/github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway/descriptor/services.go:146:49: opts.ResponseBody undefined (type *annotations.HttpRule has no field or method ResponseBody)

This commit is responsible for that: e679739

That just broke our master, and I see that the CI here isn't running as well on that commit.

@johanbrandhorst
Copy link
Collaborator

Can you retry this? We think this might be fixed already. See #730 and #712 (comment)

@johanbrandhorst
Copy link
Collaborator

johanbrandhorst commented Aug 17, 2018

Also the backup fix for this is just to merge #730

@ivucica
Copy link
Collaborator

ivucica commented Aug 17, 2018

I've just ran this test case and this has worked for me.

I also see no issue on the CI here.

Please reopen if you still see issues you directly correlate to the quoted commit.

@ivucica ivucica closed this as completed Aug 17, 2018
@kasuboski
Copy link

I just got this with v1.5.0. Is it fixed somewhere else?

@johanbrandhorst
Copy link
Collaborator

It should definitely be fixed. What exact error are you getting? You may need to update other repos in your gopath

@kasuboski
Copy link

kasuboski commented Sep 12, 2018

This is using go1.11 outside of my gopath.

go get -u github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway

go: finding github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway latest

# github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway/descriptor

../../go/pkg/mod/github.com/grpc-ecosystem/[email protected]/protoc-gen-grpc-gateway/descriptor/services.go:146:49: opts.ResponseBody undefined (type *annotations.HttpRule has no field or method ResponseBody)

@johanbrandhorst
Copy link
Collaborator

Yeah we're working on go.mod support, we're not quite there yet. Could you open an issue for go mod support?

@Tommy-42
Copy link

Tommy-42 commented Oct 1, 2018

hi there,

I have this one :

Note: checking out 'tags/v1.5.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 8558711 Generate release notes for v1.5.0

# github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway/descriptor
descriptor/services.go:146:49: opts.ResponseBody undefined (type *annotations.HttpRule has no field or method ResponseBody)

I am doing this :

GRPC_GATEWAY_REPO=github.com/grpc-ecosystem/grpc-gateway

go get -d $(GRPC_GATEWAY_REPO)/...
cd $(GOPATH)/src/$(GRPC_GATEWAY_REPO) && git checkout tags/v1.5.0
cd $(GOPATH)/src/$(GRPC_GATEWAY_REPO)/protoc-gen-grpc-gateway && go install
cd $(GOPATH)/src/$(GRPC_GATEWAY_REPO)/protoc-gen-swagger && go install

my go version is :

✗ go version
go version go1.10 darwin/amd64

FYI : running on OSX High Sierra v10.13.6

@ivucica
Copy link
Collaborator

ivucica commented Oct 1, 2018

@Tommy-42 As far as I can tell, ResponseBody field is in the current upstream pregenerated HttpRule.

https://github.com/google/go-genproto/blob/c7e5094acea1ca1b899e2259d80a6b0f882f81f8/googleapis/api/annotations/http.pb.go#L325

Not sure why the version you have would not include this. I have not looked into how vgo / go.mod works; does upstream need to tag their repo in some way?

Why are you specifically checking out grpc-gateway v1.5.0?

@Tommy-42
Copy link

Tommy-42 commented Oct 1, 2018

Hmmm I am gonna check why our googleapi annotations could be different.

We had a problem with the oneof at the root of the message ( cf #413 #416 ) constraining us to use a fork with oneof support.

So I wanted to try with the v1.5.0 to see if it was fixed

@ensonic
Copy link
Contributor

ensonic commented Nov 6, 2018

Getting the same issue when pulling the new version into a bazel build.

@johanbrandhorst
Copy link
Collaborator

What does that mean? Do we need to update some Bazel dependency versions? Why is CI passing 🤔?

@ensonic
Copy link
Contributor

ensonic commented Nov 6, 2018

I believe it is related to you shipping a copy of the annotations.proto here:
https://github.com/grpc-ecosystem/grpc-gateway/tree/master/third_party/googleapis/google/api
Is there a reason for you to not use the upstream version?

@ivucica
Copy link
Collaborator

ivucica commented Nov 6, 2018

Getting the same issue when pulling the new version into a bazel build.

Can you clarify "the same"? How did you 'pull the new version in'?

I believe it is related to you shipping a copy of the annotations.proto here:

Possible, but can you clarify what led you to believe this? In what significant way are the files different?

Upstream has the response_body proto field, as does the vendored copy.

Is there a reason for you to not use the upstream version?

How would you use it? One still needs to pick an upstream version to lock onto and to download, for consistent builds, right?

If we didn't lock onto it (whether by copying or specifying the exact version in http_file() in Bazel), we'd get broken if upstream breaks things.

It's also not without benefit to have a copy of the .proto file around in a nice and convenient well-known path, already cloned and usable by developers for import purposes when using protoc. (I'm thinking of my usual workflow with a GOPATH; I can invoke go generate which invokes protoc extending import path to include ${GOPATH}/src/github.com/grpc-ecosystem/grpc-gateway/third_party. And this without having to clone the entire, somewhat large, googleapis/googleapis repo by hand.)

@ensonic
Copy link
Contributor

ensonic commented Nov 6, 2018

In my bazel WORKSPACE file:

go_repository(
    name = "grpc_ecosystem_grpc_gateway",
    #commit = "844b78d9a291695a45d1d826fda9c1b95a2ddfc1",
    #importpath = "github.com/grpc-ecosystem/grpc-gateway",
    # TODO(ensonic): switch back after PR #644 has been merged
    commit = "4e0ecd0f283a990d61c867c2e55635a11931e2aa",
    importpath = "github.com/ensonic/grpc-gateway",
)

The uncommented version is the time of my PR and everything builds. When I swapp to the commented part (the merged PR), then I also get all the changes in between and now the build fail:

GoCompile: error running compiler: exit status 2
home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/sandbox/linux-sandbox/43/execroot/myproject/external/grpc_ecosystem_grpc_gateway/protoc-gen-grpc-gateway/descriptor/services.go:146:49: opts.ResponseBody undefined (type *annotations.HttpRule has no field or method ResponseBody)

Somehow the build is picking up an outdated copy of the http.proto. I am digging deeper.

$ find home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/ -name "http.proto"
/home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/external/com_github_googleapis_googleapis/google/api/http.proto
/home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/external/go_googleapis/google/api/http.proto
/home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/external/grpc_ecosystem_grpc_gateway/third_party/googleapis/google/api/http.proto
/home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/external/bazel_source/third_party/googleapis/google/api/http.proto

$ find /home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/ -name "http.proto" -exec grep -Hn "response_body" {} \;
/home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/external/com_github_googleapis_googleapis/google/api/http.proto:355:  string response_body = 12;
/home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/external/go_googleapis/google/api/http.proto:355:  string response_body = 12;
/home/ensonic/.cache/bazel/_bazel_ensonic/556f802681b2087c6d9a6bcc3d0d954b/external/grpc_ecosystem_grpc_gateway/third_party/googleapis/google/api/http.proto:303:  string response_body = 12;

So the bazel_source/third_party/googleapis/google/api/http.proto is too old and for some reason it hit this one.

@ivucica
Copy link
Collaborator

ivucica commented Nov 6, 2018 via email

@ivucica
Copy link
Collaborator

ivucica commented Nov 6, 2018

I've discussed this with @ensonic out-of-band. It was a local (but interesting) issue with the WORKSPACE file, not a bug in grpc-gateway's rules.

@ensonic
Copy link
Contributor

ensonic commented Nov 6, 2018

SOLVED: We also imported org_golang_google_genproto in our WORKSPAE but at an older version,w hich apparently shadowed yours. Sorry for the noise.

@dv29
Copy link

dv29 commented Jan 12, 2019

Hi, I am facing this issue when I try to go get github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway

@johanbrandhorst
Copy link
Collaborator

If you're getting this error, make sure you are using the latest available version of the http.proto file.

@ivucica
Copy link
Collaborator

ivucica commented Jan 13, 2019

This particular issue is long resolved. Unless it's related to the original issue related to response_body, I don't think it's right to keep posting here.

I'll lock this issue.

@grpc-ecosystem grpc-ecosystem locked as resolved and limited conversation to collaborators Jan 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants