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

feat: forward compatible diregapic LRO support #1085

Merged
merged 5 commits into from
Nov 17, 2021

Conversation

software-dov
Copy link
Contributor

Detect whether a method fulfills the criteria for DIREGAPIC LRO.
If so, fudge the name of the generated method by adding the suffix
'_primitive'. This change is made for both the synchronous and async
client variants. Any generated unit tests are changed to use and
reference the fudged name.

The names of the corresponding transport method is NOT changed.

Detect whether a method fulfills the criteria for DIREGAPIC LRO.
If so, fudge the name of the generated method by adding the suffix
'_primitive'. This change is made for both the synchronous and async
client variants. Any generated unit tests are changed to use and
reference the fudged name.

The names of the corresponding transport method is NOT changed.
@software-dov software-dov requested a review from a team as a code owner November 13, 2021 00:19
@google-cla google-cla bot added the cla: yes This human has signed the Contributor License Agreement. label Nov 13, 2021
Copy link
Contributor

@vam-google vam-google left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thanks for doing it. I have only one major comment: most probably we would need to populate https://github.com/googleapis/python-api-common-protos with externded_operations stuff (see the corresponding comment for details), like we have done with the other langauges.

Another question: have we agreed on the _primitive suffix? I do not have a strong opinion on the suffix itself, as long as it is as consistent as possible with other languages.

@@ -0,0 +1,132 @@
# -*- coding: utf-8 -*-
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we need to add these files into
https://github.com/googleapis/python-api-common-protos/tree/main/google

We have done simiilar procedure in other langauges already, for example:
Java: https://github.com/googleapis/java-common-protos/tree/main/proto-google-common-protos/src/main/java/com/google/cloud

Ruby: https://github.com/googleapis/common-protos-ruby/tree/main/google-cloud-common/lib/google/cloud

Once we do that, I believe we can remove most of these files from this PR.

Copy link
Contributor

@busunkim96 busunkim96 Nov 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/googleapis/python-cloud-common/tree/main/google/cloud/common/types was created for google/cloud/common_resources.proto, so I think it will be a more appropriate repo/package for extended_operations.proto.

Can the BUILD.bazel https://github.com/googleapis/googleapis/blob/master/google/cloud/BUILD.bazel be updated to generate this proto as well?

Another note, we've switched to generating proto-plus types by default instead of _pb2.py, will that be a problem for the generator or generated library code? @software-dov

I'm happy to assist with getting the protos published to the appropriate package once the questions above are sorted out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/googleapis/googleapis/blob/master/google/cloud/BUILD.bazel#L51 already has a python target for extended_operations. But that one will create default stubs. If you want generate proto-plus ones, then it is still straightforward, but woluld require changing that target to py_gapic_library and py_gapic_assembly targets instead. I'm happy to assist with that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The extended_operations_pb2.py file is just used by the generator; I don't believe generating proto-plus types will work because proto-plus can't handle message extensions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vam-google The other files added to the PR are necessary for the fragment tests. The only file that can and should be moved is extended_operations_pb2.py.

@software-dov
Copy link
Contributor Author

@vam-google with regards to the _primitive suffix: the forward compatible LRO doc does not indicate that there is a consensus formed. Ruby does not use that naming convention, and it looks like go doesn't either.

@vam-google
Copy link
Contributor

@software-dov Which ones do ruby and go use?

Copy link
Contributor

@vam-google vam-google left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but please first finalize the suffix we want to use for this (_primitive or something else) with @vchudnov-g, and upate this PR accordingly to feature the proper suffix.

tests/fragments/test_diregapic_forwardcompat_lro.proto Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants