Open siudeks opened 4 months ago
May you convert the issue to a bug reporting please? Mentioned types are part of DAPR java sdk, and they do not exist in Python sdk
@siudeks this is generated code - generated from protos. Not all generated proto functionality is used in the Python SDK, and that is expected behavior. Please focus on the features you are looking for.
The source is here: https://github.com/dapr/dapr/blob/master/dapr/README.md
You can compile those protos to Python using the instructions here: https://github.com/dapr/python-sdk/tree/main/tools
That being said, just because something exists in the Dapr Runtime proto does not mean we are going to use it or implement it in the Python SDK.
This is working as intended.
If it makes things clearer, I will move the proto
package to _internal/proto
or something like that.
For some more background - the Dapr GRPC client is the only official way in Python to interact with GRPC. Using the protos directly is not supported by the Python SDK maintainers.
https://github.com/dapr/python-sdk/tree/main/dapr/clients/grpc
If you take a look there you will see that this imports and uses a subset of the generated functions from the private/internal proto package.
The dapr-ext-grpc
extension (code here: https://github.com/dapr/python-sdk/tree/main/ext/dapr-ext-grpc/dapr/ext/grpc) also uses some of those protos.
@berndverst if it is intended limitation -> I understand
In my scenarios I consume events via gRpc connection with DAPR sidecar, so initially @app
was the very good starter. Actually, @app
does not support atm async methods, what I exactly wanted to achieve
If there is a way to subscribe events using grpc connection with DAPR, where my listeners are async - in such case I will not require app callback generated classes
@siudeks it should be pretty easy to make an async version of dapr-ext-grpc
. Ultimately that package is fairly simple, and indeed you could just create a grpc client from grpc.aio
instead of grpc
and use the protos we generated (just basically copy whatever we do for the sync version but make it async).
Let me change this issue into a feature request for an async grpc pubsub / events subscriber
Some notes on desired implementation details:
Just like we have dapr.ext.grpc
which export App
and Rule
, we should have dapr.ext.grpc.aio
which export the same. The only usage difference should be this single import.
The grpc connection needs to be established using grpc.aio
instead of grpc
.
And the internal topic / event handler registration needs to be changed to an awaitable type. Change functions to be awaitable, and await any results.
How to import classes defined here?
The question is about grpc generated stuff like ListTopicSubscriptionsResponse, TopicSubscription, TopicEventRequest, TopicEventResponse etc. They are required to use DAPR in intellisense-friendly way, as the classes are part of DAPR appcallback interface.
They do not exist in DAPR-related pypi modules, what makes impossible to create type-safe code based on DAPR grpc callback services