unable to import both major versions of appengine at the same time due to internal protos #311
Comments
|
The issue: |
|
Thanks for the cross links. If that issue is #281 is reopened I will close this. But I do believe this is a problem worth fixing or at least there needs to be more conversation on the issue to why it was closed. The Go module ecosystem is friendly to people importing multiple major versions at once -- having both import should not cause panics. |
|
I agree that it should be fixed. I'm stuck using old versions of unrelated libraries because of this issue. |
Yes, it's a fair behavior that we should support. We will reserve some time in our next sprint to at least working on a proposal. |
|
After reading some of the related issues (googleapis/google-cloud-go#7760, #281 and #228), it appears that migrating from github.com/golang/protobuf to google.golang.org/protobuf is the short-term solution. One common challenge of this type of issues is that Google's internal code base and OSS repos may diverge. We might be lucky here because this Github repo is the source of truth if I recall correctly. I can (or ask someone in our team) to give this change a shot. |
|
@jinglundong any estimates for resolution? |
|
Sorry for being irresponsive on this issue. I will provide an estimate next week. |
|
This issue aligns with an internal goal of our team. The current ETA is June 30th 2023. |
|
An update: this issue didn't make to our current sprint ending on June 27th 2023. The new ETA is by the end of Q3 2023. |
|
Unfortunate of course, however I would like to thank you for keeping us informed. Very rare trait for a googler! |
This should be wire compat as field numbers did not change and package is not apart of the serialization. I appened `.v2` to each proto package so that these protos can register distinctly from the protos that were copied from the v1 library. This removes runtime errors due to double registration of the same messages. Note: I did have to specially regenerate taskqueue with a special built version of protoc-gen-go in order to generate some proto1 legacy message type that is referenced. Fixes: golang#311 Fixes: googleapis/google-cloud-go#7760
This should be wire compat as field numbers did not change and package is not apart of the serialization. I appened `.v2` to each proto package so that these protos can register distinctly from the protos that were copied from the v1 library. This removes runtime errors due to double registration of the same messages. Note: I did have to specially regenerate taskqueue with a special built version of protoc-gen-go in order to generate some proto1 legacy message type that is referenced. Fixes: #311 Fixes: googleapis/google-cloud-go#7760
This should be wire compat as field numbers did not change and package is not apart of the serialization. I appened `.v2` to each proto package so that these protos can register distinctly from the protos that were copied from the v1 library. This removes runtime errors due to double registration of the same messages. Note: I did have to specially regenerate taskqueue with a special built version of protoc-gen-go in order to generate some proto1 legacy message type that is referenced. Fixes: #311 Fixes: googleapis/google-cloud-go#7760
Please see issue for more context: googleapis/google-cloud-go#7760
Although theses deps should likely be updated it should not break users if they have both imported at the same time. The internal protos should have a new namespace for the v2 library to make the global protobuf registry happy.
The text was updated successfully, but these errors were encountered: