Repository navigation
fix(samples): install the stream sample's Stream protos into temporalio - #311
Conversation
fc0ccdc to
775b87d
Compare
fec09fb to
92cfcc2
Compare
2f6b64b to
4391281
Compare
2f28526 to
2497fc5
Compare
4391281 to
3ff91ac
Compare
2497fc5 to
52b7104
Compare
3ff91ac to
54da5a5
Compare
52b7104 to
e00ebe2
Compare
…#310) ### What changed? This PR plans a protobuf `oneof` case that names a proto-bound WIT record as that record, as nexgen already does for a record field. - Only oneof-bound variants get the new plan, and an `option` around the payload stays. - A .NET case record names its payload's model in full. Else a case named like its record hides the model, and `record Superseded(Superseded Value)` doesn't compile. Brook's next WIT names a case like that. - The first commit is the fix, and the stream sample's TypeScript output appears with it. The second commit generates the stream service for Python, with basedpyright off for it until #311. `tsc` skips the service until #296. In the stream sample's .NET output, the read item now holds the records, not the proto classes. It's based on #308. ### Why? Brook's read item, `variant stream-item`, binds a `oneof` of three proto-bound records. Before the fix, Python and TypeScript generation panicked on it, and .NET typed each case as the proto class. ### How did you test it? Link to a test plan if any - - [x] Unit Tests - [ ] Staging - [ ] End to End Tests New TypeScript and .NET tests round-trip the read item's cases, and the .NET test leaves out the data case. A unit test covers the full name of a case payload. Co-authored-by: Tim Conley <timothy.conley@temporal.io>
25efbe1 to
eb8425d
Compare
eb8425d to
79f16e2
Compare
moetemp
changed the title
| requires-python = ">=3.10" | ||
|
|
||
| [build-system] | ||
| requires = ["hatchling"] |
There was a problem hiding this comment.
It's a third-party build backend for Python packages, from the Hatch project. We don't need it, so I switched to uv_build, uv's own backend, in e1bfd59. uv installs a local path dependency by building a wheel from it, so the package still needs a backend, but now it's the one from uv.
moetemp
changed the title
| # The Python modules of the Stream protos of temporalio/api#895 (A1), at the paths where | ||
| # temporalio will have them. Drop this package once a temporalio release has A1. | ||
| [project] | ||
| name = "temporalio-a1-overlay" |
There was a problem hiding this comment.
What's the reason for the whole separate package overlay thing? Was there a problem with putting them in the original project?
There was a problem hiding this comment.
Yes, there was a problem. The generated stream_service code imports temporalio.api.stream.v1, which is where a temporalio release will have these modules. Python looks for temporalio.api.stream only inside the installed temporalio, since temporalio is a normal package. So a temporalio/ folder in the sample project either hides the real temporalio, or Python skips it. basedpyright follows the same rule. That's why main keeps the copies in streamprotos/, at another import path, and basedpyright skips wit/stream_service.
The small local package fixes this, because uv installs its files into the installed temporalio. When a release has these protos, we delete it. I put the reason in a comment in 58790da. I also renamed the package to temporalio-stream-protos, since "A1" was only our internal name for api#895.
The other option is a conftest.py that adds the folder to temporalio.api.__path__. It needs no package, and it works for the tests. But basedpyright can't follow it, so it would keep skipping wit/stream_service.
79f16e2 to
58790da
Compare
The stream output imports the Stream protos from temporalio.api, where a temporalio release with the Stream protos will have them. A local package installs them there until then, so the tests and basedpyright run on the stream service.
e1bfd59 to
7b059e6
Compare
What changed?
This PR moves the stream sample's Python bindings of the Stream protos into a local package,
temporalio_stream_protos/, that installs them intotemporalio. Only the sample changes. nexgen and the generated code stay as they are.temporalio/api/. The sample depends on it through auvpathsource, andstreamprotos/goes away.wit/stream_service.Why?
The Stream protos of
temporalio/api#895aren't in a releasedtemporalioyet. The generated code already imports them fromtemporalio.api, where a release will have them. When it does, the package goes away.How did you test it?
Link to a test plan if any -
test_stream_service.pyround-trips each read item kind through thetemporalio.apiclasses.