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
samples: add samples #37
Conversation
assert "created successfully." in out | ||
|
||
|
||
def test_update_lite_topic_example(topic_path, capsys): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A small concern that this test depends on the execution order. Probably not a big deal.
* fix: Move types to common directory Also move internal-only files to internal directory. * fix: Fix test imports
subscription_path = SubscriptionPath(project_number, location, subscription_id) | ||
|
||
subscription = Subscription( | ||
name=str(subscription_path), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re: str()
, it might be a library usability issue, but isn't it better if we can just pass the SubscriptionPath as the argument? Is it possible to do it in the constructor? Feel free to ignore, or file a new issue and fix later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This type is a proto, so unfortunately not unless we want to wrap the proto.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so nevermind.
There was a problem hiding this comment.
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-pubsublite/blob/master/google/cloud/pubsublite/types/paths.py looks like a handwritten file to me.
The generator usually produces methods to construct and decompose paths (see examples in AutoML). https://aip.dev/client-libraries/4231
Did that not happen for pubsublite?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It produces methods but not types. These methods (like
def subscription_path(project: str, location: str, subscription: str,) -> str: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They also don't type check the current restriction (that we're trying to remove in the backend) that only project numbers be used in the path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those methods did get generated for pubsublite but they aren't used.
Topic paths are created by a publisher client in Pub/Sub but by an admin client in Pub/Sub Lite.
# This looks cumbersome.
client = AdminClient(cloud_region)
topic_path = client.topic_path(project_number, location, topic_id)
with PublisherClient() as publisher_client:
api_future = publisher_client.publish(topic_path, data.encode("utf-8"))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah okay, thanks for the explanation. 👍
Was there a decision made that pubsublite is not going to support project IDs? https://google.aip.dev/cloud/2510 I haven't been looking at all these PRs so apologies if this is digging up an old conversation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its the difference between "must" and "should". Its nontrivial work to convert between the two and it has not been addressed until this quarter. I've sent you the internal link from the elysium team that clarifies this guidance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The discussion was in internal b/162623801. Java currently accepts both. Python/Go will wait for this change on the server side.
data = f"{message}" | ||
api_future = publisher_client.publish(topic_path, data.encode("utf-8")) | ||
# result() blocks. To resolve API futures asynchronously, use add_done_callback(). | ||
message_id = api_future.result() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re: result()
, is there a hard deadline, or will it block forever?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
result() can take an optional timeout argument, by default, it blocks forever unless it errors out first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have timeout then? I think we should avoid infinite wait if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's rare for result() to fail. In the case of failure, the client library will retry publish if no timeout is provided (as is the case for Pub/Sub too). I think not adding timeout is what most people want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I can live with that, but keep in mind if a rare case happens, the code will indefinitely wait.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once two comments are addressed.
Testing:
Samples are tested as part of the required test
pubsublite-build
. They can be also tested using the following commands locally:Summary:
This PR includes the following samples and all their tests are in
./quickstart_test.py
:Note to reviewer:
Please expect this PR to have theUpdate: These issues have been addressed.do not merge
label as we work to polish the library. Below are some issues I have identified the library. Your reviews can be used for support and/or to open additional issues.Admin, publisher, and subscriber client import and creation are atypical. issue: atypical client creation #45Publisher futures do not return outside a context manager. issue: publish future hangs when a context manager is not used #46make_subscriber()
does not return a subscriber client but a streaming pull future. issue: make_subscriber() doesn't make a subscriber #47Admin client expects a string but publisher and subscriber clients expect typed objects for resource names. issue: make clients accept strings and typed objects for resource names #48FlowControlSettings
in the subscriber example should ideally be created as a type:from google.cloud.pubsublite.types import FlowControlSettings
. RefactorFlowControlSettings
undergoogle.cloud.pubsublite.types
#49Consider bringing the following undergoogle.cloud.pubsublite.types
: a) Classes ingoogle.cloud.pubsublite.location
b) Classes ingoogle.cloud.pubsublite.paths
c) Classes ingoogle.cloud.pubsublite.endpoints
. Refactor paths/location/endpoints undergoogle.cloud.pubsublite.types
#50