Please sync google/api/http.proto from github.com/googleapis/googleapis

[ivucica]

Recent regeneration commits have steamrolled over response_body field required for grpc-ecosystem/grpc-gateway#712.

This seems because the http.proto not based on the last http.proto. It was overwritten in 9739b9a.

Formerly-internal-only response_body has been made public in this sync commit googleapis/googleapis@3544ab1

https://github.com/googleapis/api-common-protos has not been synced for months (since July).

Can someone make sure that 3544ab16c3342d790b00764251e348705991ea4b makes it into the regenerated file?

[ivucica]

FWIW @jadekler I'm attempting to merge googleapis/api-common-protos#12 which may be the correct way to resolve this problem.

Alternatively, is there a reason to depend on that extra repo, if all the googleapis/api-common-protos are also present in googleapis/googleapis?

.oO { It's a shame copybara does not sync to that lightweight repo. }

[ivucica]

Aaaaaaand it just got merged. That was fast! So just regeneration would fix this.

I don't have an up-to-date protoc readily available, can you do it?

[jeanbza]

Yes, doing so now.

[jeanbza]

Merged. To recap my understanding of this problem (any of this may be wrong and I'm happy to be corrected):

• googleapis/googleapis contains api-specific protos as well as general-purpose protos, such as http.proto
• googleapis/api-commons-protos is a copy of the general-purpose protos from googleapis/googleapis, intended to be the future home of the general-purpose protos
• googleapis/googleapis http.proto got a response_body field in googleapis/googleapis@3544ab1
• This was used to generate the ResponseBody field in go-genproto's http.pb.go
• It's possible that sometime between then and the latest go-genproto regeneration, artman was updated to use googleapis/api-commons-protos for http.proto
• In the latest go-genproto regeneration, the ResponseBody field was wiped away because http.proto in googleapis/api-commons-protos does not have the response_body field (it had only been added to googleapis/googleapis)

This was fixed by:

• Manually adding response_body to googleapis/api-commons-protos in google/api/http.proto: Add response_body. api-common-protos#12
• Re-generating go-genproto

Action items:

• Perhaps googleapis/api-commons-protos should be synced from googleapis/googleapis periodically, or perhaps we should put deprecated notices on googleapis/googleapis protos that now live in googleapis/api-commons-protos

[lukesneeringer]

Alternatively, is there a reason to depend on that extra repo, if all the googleapis/api-common-protos are also present in googleapis/googleapis?

To answer this question:
We are more or less in a transitionary mode.

It turns out that there are several problems with having a single repo (googleapis) that houses both the common / dependency protos, and the specific API protos. The problems essentially amount to that the story for external usage ("make your own API protos that can use our common ones as dependencies") is terrible, and it is also really unclear what API producers are allowed to depend on.

We are trying to fix that problem by delineating between our common protos and our specific API protos, and the common ones should eventually no longer be in googleapis. However, removing them now would essentially break the world, thus the overlap.

It is not great, and we are working on it. :-) It is just a marathon and not a sprint.