Skip to content

Get Python apps working again after Viceroy WIT updates etc.#10

Merged
erikrose merged 23 commits into
mainfrom
get-wasiless-working-with-flask
Oct 20, 2025
Merged

Get Python apps working again after Viceroy WIT updates etc.#10
erikrose merged 23 commits into
mainfrom
get-wasiless-working-with-flask

Conversation

@erikrose
Copy link
Copy Markdown
Member

@erikrose erikrose commented Oct 16, 2025

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-2 branch of Viceroy, which increases the allowed number of memories to 2 to allow the wasiless component to fit. The CI job uses a tag on that branch.

Also…

  • Switch to self-hosted testrunners, because the GH-hosted ones will quit working in our org in a few days. Bonus: building Viceroy takes 25s instead of 2m.
  • Cache builds of Viceroy and other tools for speed, bringing a warm CI run to about 1m. We could cache further if we wanted.
  • Sync up with Viceroy's latest WIT files.
  • Support an env var to prefer a specific path to Viceroy.

erikrose and others added 14 commits October 8, 2025 10:41
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.
@erikrose erikrose requested a review from posborne October 16, 2025 20:51
@erikrose erikrose force-pushed the get-wasiless-working-with-flask branch 2 times, most recently from 2dd32f4 to 186413d Compare October 16, 2025 21:37
@fastly-forge-auditor
Copy link
Copy Markdown

⚠️ ⚠️ ⚠️ Future executions of the workflow Python CI will be aborted starting in 12 days due to the usage of non-approved GitHub runner labels.
Offending label: [ubuntu-latest]


Please, contact Developer Platform at #ci-support if you need help using Forge runners

@fastly-forge-auditor
Copy link
Copy Markdown

⚠️ ⚠️ ⚠️ Future executions of the workflow Python CI will be aborted starting in 11 days due to the usage of non-approved GitHub runner labels.
Offending label: [ubuntu-latest]


Please, contact Developer Platform at #ci-support if you need help using Forge runners

@erikrose erikrose force-pushed the get-wasiless-working-with-flask branch from 4909933 to 85e8fdb Compare October 17, 2025 15:44
@erikrose
Copy link
Copy Markdown
Member Author

erikrose commented Oct 17, 2025

The problem is that wasiless can't be checked out as a submodule because it's an Internal repo. [Fixed.]

@erikrose erikrose force-pushed the get-wasiless-working-with-flask branch from 78b7004 to fd73e6a Compare October 17, 2025 18:49
* 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.
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.
Copy link
Copy Markdown
Member

@posborne posborne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@erikrose
Copy link
Copy Markdown
Member Author

erikrose commented Oct 20, 2025

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!

@erikrose erikrose merged commit 22891f2 into main Oct 20, 2025
3 checks passed
@erikrose erikrose deleted the get-wasiless-working-with-flask branch October 20, 2025 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants