You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In terms of categorizing errors, we could hook into the error => Status mapping here.
Categorization of output values will be a bit harder. We could ask users to wrap values before returning them from their functions, and then add categorization and serialization hooks to the wrapper. This is essentially what we've done with the dispatchhttp package. Ideally though users should be able to return whatever value they like, and we do the wrapping automatically.
Another difference compared to Python is the inability to detect whether a dependency has been imported, so that we can dynamically import the integration (1). An alternative is to host integrations as submodules and have the submodules register integrations using an init hook. The user could then import the integration with an underscore/side-effect import. This is what we've done elsewhere.
The text was updated successfully, but these errors were encountered:
The Python SDK has a set of integrations, that enable categorization of error and output values from various SDKs and APIs. See https://github.com/dispatchrun/dispatch-py/tree/main/src/dispatch/integrations
We should integrations here too.
In terms of categorizing errors, we could hook into the
error
=>Status
mapping here.Categorization of output values will be a bit harder. We could ask users to wrap values before returning them from their functions, and then add categorization and serialization hooks to the wrapper. This is essentially what we've done with the
dispatchhttp
package. Ideally though users should be able to return whatever value they like, and we do the wrapping automatically.Another difference compared to Python is the inability to detect whether a dependency has been imported, so that we can dynamically import the integration (1). An alternative is to host integrations as submodules and have the submodules register integrations using an
init
hook. The user could then import the integration with an underscore/side-effect import. This is what we've done elsewhere.The text was updated successfully, but these errors were encountered: