Get Python apps working again after Viceroy WIT updates etc. by erikrose · Pull Request #10 · fastly/compute-sdk-python

erikrose · 2025-10-16T20:51:18Z

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.

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.

fastly-forge-auditor · 2025-10-16T21:37:30Z

⚠️⚠️⚠️ 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 · 2025-10-17T15:40:39Z

⚠️⚠️⚠️ 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 · 2025-10-17T16:23:22Z

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

* 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.

posborne

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 · 2025-10-20T16:02:58Z

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 · 2025-10-16T20:51:18Z

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.

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.

fastly-forge-auditor · 2025-10-16T21:37:30Z

⚠️⚠️⚠️ 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 · 2025-10-17T15:40:39Z

⚠️⚠️⚠️ 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 · 2025-10-17T16:23:22Z

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

* 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.

posborne

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 · 2025-10-20T16:02:58Z

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 · 2025-10-16T20:51:18Z

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.

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.

fastly-forge-auditor · 2025-10-16T21:37:30Z

⚠️⚠️⚠️ 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 · 2025-10-17T15:40:39Z

⚠️⚠️⚠️ 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 · 2025-10-17T16:23:22Z

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

* 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.

posborne

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 · 2025-10-20T16:02:58Z

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 · 2025-10-16T20:51:18Z

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.

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.

fastly-forge-auditor · 2025-10-16T21:37:30Z

⚠️⚠️⚠️ 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 · 2025-10-17T15:40:39Z

⚠️⚠️⚠️ 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 · 2025-10-17T16:23:22Z

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

* 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.

posborne

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 · 2025-10-20T16:02:58Z

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 · 2025-10-16T20:51:18Z

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.

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.

fastly-forge-auditor · 2025-10-16T21:37:30Z

⚠️⚠️⚠️ 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 · 2025-10-17T15:40:39Z

⚠️⚠️⚠️ 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 · 2025-10-17T16:23:22Z

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

* 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.

posborne

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 · 2025-10-20T16:02:58Z

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 · 2025-10-16T20:51:18Z

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.

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.

fastly-forge-auditor · 2025-10-16T21:37:30Z

⚠️⚠️⚠️ 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 · 2025-10-17T15:40:39Z

⚠️⚠️⚠️ 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 · 2025-10-17T16:23:22Z

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

* 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.

posborne

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 · 2025-10-20T16:02:58Z

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 · 2025-10-16T20:51:18Z

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.

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.

fastly-forge-auditor · 2025-10-16T21:37:30Z

⚠️⚠️⚠️ 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 · 2025-10-17T15:40:39Z

⚠️⚠️⚠️ 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 · 2025-10-17T16:23:22Z

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

* 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.

posborne

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 · 2025-10-20T16:02:58Z

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 · 2025-10-16T20:51:18Z

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.

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.

fastly-forge-auditor · 2025-10-16T21:37:30Z

⚠️⚠️⚠️ 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 · 2025-10-17T15:40:39Z

⚠️⚠️⚠️ 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 · 2025-10-17T16:23:22Z

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

* 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.

posborne

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 · 2025-10-20T16:02:58Z

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!

erikroseand others added 14 commits October 8, 2025 10:41

Update http WASI package to the version used in wasiless.
1431c4b
This shouldn't matter, but it's one less thing to conflict.

Update compute.wit to match Viceroy main at f6b6b1045ce5e1f61cbecf4…
94d2b33
…bbcc9e92e43545224. I don't know that it makes any difference, but now it matches wasiless'.

Add poll to compute.wit.
14af8d3
This solves the immediate `pollable` type mismatch when `wac`ing together a Python component.

Say "python" rather than "app".
bbdfa5c
It makes it easier for me to follow.

Sync up viceroy world with Viceroy.
f63a042
That means deleting it and referencing the `fastly:compute/service` world directly. It covers all the imports and exports we need.

Vendor wasiless and model wac composition in Makefile
156c02e

Target wasm32-unknown-unknown with wasiless
f9a0bea
Then use wasm-tools component new to transform to a component for use with wac.

Comment out WAC mappings that result in link errors.
d743cc4
This illustrates the contrast in behavior between leaf and non-leaf WIT interfaces and positions us to move forward inch by inch.

Remove export of things we don't need.
d812c6c
As far as Viceroy is concerned, we need export only `http-incoming`.

Switch to a WAC file and version of wasiless that allows the app to l…
01cc2f9
…ink and run, culminating in a Python traceback. Delegate to the wasiless repo for building the wasiless component.

Allow a locally built Viceroy to be subbed in via env var.
018855d

Clean up WAC exports.
887260f

erikrose requested a review from posborne October 16, 2025 20:51

erikrose force-pushed the get-wasiless-working-with-flask branch 2 times, most recently from 2dd32f4 to 186413dCompare October 16, 2025 21:37

erikrose force-pushed the get-wasiless-working-with-flask branch from 4909933 to 85e8fdbCompare October 17, 2025 15:44

erikrose force-pushed the get-wasiless-working-with-flask branch from 78b7004 to fd73e6aCompare October 17, 2025 18:49

erikrose added 8 commits October 17, 2025 16:15

Flask and Bottle examples now work!
190f764
* 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.

Make tests pass.
bfb2e86
They were just pointed at the components that lacked wasiless.

Stop ignoring top-level wasms, which we don't make anymore.
aa42fa1

Ditch an unused import.
ac698e8

Switch to the 2-memories-having version of Viceroy in CI so the `wasi…
2844623
…less` component fits.

Switch to self-hosted CI runners.
6776b89

Check out wasiless using a deploy key.
7c4339c
Doing it more straightforwardly doesn't work, as the CI runner has no privs to check out internal repos, even from the same org.

Add what we need to build wasiless.
1f3ec06

Cache Viceroy build, because it takes 10 minutes.
5def5e2
Switch to a tag for a simple way of telling when the cache should be invalidated: the tag changes.

erikrose force-pushed the get-wasiless-working-with-flask branch from 9646006 to 5def5e2Compare October 17, 2025 20:17

erikrose mentioned this pull request Oct 17, 2025
Update to the WITs at the present tip of the dgohman-fastly/sync-wit branch of Viceroy. #9
Closed

posborne approved these changes Oct 20, 2025
View reviewed changes

erikrose merged commit 22891f2 into mainOct 20, 2025
3 checks passed

erikrose deleted the get-wasiless-working-with-flask branch October 20, 2025 16:10