Get Python apps working again after Viceroy WIT updates etc.#10
Conversation
This shouldn't matter, but it's one less thing to conflict.
…stubs.
Note both flask-app.wasm and wit-bottle.wasm have identical WIT (and thus imports), so one should link if the other does.
Current error:
```
% wac compose --dep fastly:wasiless=../wasiless/componentized.wasm --dep app:component=build/wit-bottle.wasm -o composed.wasm wrap_app_in_wasiless.wac
error: the encoding of the graph failed validation
Caused by:
type mismatch for import `wasi:filesystem/types@0.2.0`
type mismatch in instance export `input-stream`
resource types are not the same (ResourceId { globally_unique_id: 2, contextually_unique_id: 134 } vs. ResourceId { globally_unique_id: 2, contextually_unique_id: 6 }) (at offset 0x2916624)
```
…he imports of `wit-bottle.wasm`. In other words, this "should work". Specifically, revise the wac to not import anything that is provided by the Compute `service-imports` world. Those items should be provided directly by the host (Viceroy or similar), as then it will actually be functional. Add in `poll`, as Python imports it but `service-imports` does not (so it's not provided to services by the host).
…bbcc9e92e43545224. I don't know that it makes any difference, but now it matches wasiless'.
This solves the immediate `pollable` type mismatch when `wac`ing together a Python component.
It makes it easier for me to follow.
That means deleting it and referencing the `fastly:compute/service` world directly. It covers all the imports and exports we need.
Then use wasm-tools component new to transform to a component for use with wac.
This illustrates the contrast in behavior between leaf and non-leaf WIT interfaces and positions us to move forward inch by inch.
As far as Viceroy is concerned, we need export only `http-incoming`.
…ink and run, culminating in a Python traceback. Delegate to the wasiless repo for building the wasiless component.
2dd32f4 to
186413d
Compare
|
Please, contact Developer Platform at #ci-support if you need help using Forge runners |
|
Please, contact Developer Platform at #ci-support if you need help using Forge runners |
4909933 to
85e8fdb
Compare
|
The problem is that wasiless can't be checked out as a submodule because it's an Internal repo. [Fixed.] |
78b7004 to
fd73e6a
Compare
* Ditch the `http_body.write()` back/front param that's no longer in the API. * Make sure wasms get rebuilt when we change wsgi.py. All endpoints now work properly when hit from a browser.
They were just pointed at the components that lacked wasiless.
…less` component fits.
Doing it more straightforwardly doesn't work, as the CI runner has no privs to check out internal repos, even from the same org.
Switch to a tag for a simple way of telling when the cache should be invalidated: the tag changes.
9646006 to
5def5e2
Compare
posborne
left a comment
There was a problem hiding this comment.
Changes here all seem reasonable; I'll need to review the conversations and wasiless changes to see how we made the composition work, but would be happy to see this land to get things back to a working state.
|
Thanks! Basically, we took the WIT imports living in component-py's output and had wasiless fulfill only those—minus what Viceroy would fulfill itself. Let me know if you have questions! |
Both example apps now link, run, and pass tests happily. We do this by interposing
wasiless, a null implementation of the WASI routines outside Viceroy's purview, which satisfies CPython's importing (and sometimes calling) of them: things like ttys and FSs.The only caveat is you have to use the
erik/python-sdk-2branch of Viceroy, which increases the allowed number of memories to 2 to allow thewasilesscomponent to fit. The CI job uses a tag on that branch.Also…