Skip to content

Merge wasiless into this repo#76

Merged
erikrose merged 51 commits into
mainfrom
erik/merge-wasiless
Apr 2, 2026
Merged

Merge wasiless into this repo#76
erikrose merged 51 commits into
mainfrom
erik/merge-wasiless

Conversation

@erikrose
Copy link
Copy Markdown
Member

@erikrose erikrose commented Apr 2, 2026

This reduces submodule paperwork for the foreseeable future. If we ever support some other runtime for which wasiless is useful, we can break it out again.

`cargo build --target wasm32-wasip2`
Also rename the top-level WIT file, which I had forgot to do.
… unready pollable. Stop doing that.

Returning seems to me much preferable to freezing forever.
…so we can build it with just `cargo build`.
Here, move binding generation to its own module.
These files aren't getting any shorter.
Starting to simply throw `unimplemented!()`. It makes the stubs faster to write, and it's not clear that eager failure isn't preferable, unless Python demands actual operational routines. It's likely I'll go back and change the present mock-ish implementations to `unimplemented!()` as well.
…nder Viceroy.

I skipped ahead using wit-bindgen to generate all the stubs to see what would happen, and I ran into a link error. It turns out that the `wasm32-wasip2` target adds a lot of extra imports, 0.2.3 WASI ones, which Viceroy doesn't provide and we obviously cannot provide to ourselves. We'll just have to wrap our output in a component ourselves with wasm-tools after building. We'll work that into the build process eventually.
Rust stdlib has no RNGs yet. `rand` crate doesn't support JS-less wasm. Perhaps the experimental RNG stuff in Rust nightly would work.
erikrose and others added 21 commits October 3, 2025 15:29
…a crash eventually.

Crash promptly so the crash is easy to track down.
…bbcc9e92e43545224.

It made no different in the WIT of the emitted component.
This solves the immediate `pollable` type mismatch when `wac`ing together a Python component.
…invocation.

See ed84dc3 for details on target selection.
This lets us substitute wasiless items in for WASI ones without `wac` having errors about conflicting resource types. (`resource` directives actually create resource-type singletons, and `wac` does not unify them. Thus, we have to give unique package paths to what would otherwise be conflicting ones.)
This reverts commit 970bd61.

This gambit didn't work. We were with the same error upon `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: 124 } vs. ResourceId { globally_unique_id: 2, contextually_unique_id: 6 }) (at offset 0x291a051)
```
…e implementations.

* Export (in the `wasiless` world) only things used by Python but not provided by the Fastly Compute runtime.
* Remove implementations of things we don't need for Python (or that are covered by Compute).
* Flatten out contents of `wit` dir. These WITs are extracted from the Python+app component and are a little non-canonical, doing things like importing 0.2.6 interfaces into `filesystem/types@0.2.0`. Let's stick with this for now, since it works.
…us to move composition to the compute-sdk-python repo.
It's 71K instead of 3MB.
This reduces submodule paperwork for the foreseeable future. If we ever support some other runtime for which wasiless is useful, we can break it out again.
@erikrose erikrose requested a review from posborne April 2, 2026 14:49
@erikrose erikrose merged commit fd13ad3 into main Apr 2, 2026
4 checks passed
@erikrose erikrose deleted the erik/merge-wasiless branch April 2, 2026 21:15
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