Prod/testsuite with wasm2go

[lbe]

No description provided.

[vados-cosmonic]

Hey @lbe as you have no doubt noticed, the implementation in-repo has changed dramatically over the last few weeks! Would you mind updating this PR to match and updating it?

Also, if you could split this PR into two PRs:

• A PR with your custom runner impl (passing w/ existing tests)
• A PR with any new components that should be part of the test suite (it may be useful to commit the WAT/source code here and add the build process to match)

If you want to close & re-open the PR that's also fine of course (you don't have to do an intense rebase in this one)

[lbe]

I guess I have totally gone nuts, I don't even remember creating a pull request back to the upstream. Nonetheless, I'm happy to have this included. I'm pretty swamped right now. I should be able to pick this up and knock it out in the next week.

[lbe]

All,

While I said it would be later this week before I could look. This kept on bothering me. I still don't remember creating a pull request. Having said that, I would like for wasm2go-wasi-host to be included as a runner. I have taken a look around this repo at more than just the tests themselves. I definitely feeling like I'm drinking from the firehose because there is so much outside of just the tests. As a result, I am requesting some guidance.

Unlike the other runners, I think, wasm2go_run needs access to a full build environment. It actually:

1. transpiles the wasm file to a Go module using an installed wasm2go binary
2. generates a Go project in a tempDir using a main.go that imports wasm2go-wasi-host and the transpiled module.
3. compiles to an executable binary
4. executes the binary

Is this approach supportable within the current wasi-testsuite build environment? I'm guessing yes and that would be part of the 2nd PR referenced above.

I can think of at least 3 ways to internalize the above into a single executable runner like wazero or wamstime; however, none of these are what I would consider to be "normal" development. Each would be more of a "frankenstein".

The alternative is for me to close this pull request and continue to use the lbe/wasi-testuite branch prod/testsuite-base as a sub-module in the lbe/wasm2go-wasi-host repo. I would probably modify this approach to eliminate the python adapter and just write run_test.py functionality in wasm2go-wasi-host. Then I could use WebAssembly/wasi-testsuite directly as a sub-module. I chose the current path because of expediency, not because it was necessarily the best long term solution.

Thanks in advance for your guidance!

Also, thank you for wasi-testsuite. It was a huge help when I started converting an application specific wasi host module to the generalized wasm2go-wasi-host. Your recent refinement regarding root paths resulted in almost all of the rust tests failing. As I dug in, I realized that some of my original code was causing the failure. I "thought" I had converted all of it to follow patterns in wazero. I was wrong. I have made the correction and all of wasip1 test again pass and I have confirmed that I am consistent with the wazero implementation. I will be generating a new release later this week.

Cheers, lbe

[andreiltd]

Hey, thanks for laying this out! I agree this is quite different from the other runtimes, and I would avoid making wasi-testsuite own the full wasm2go build environment. I think the cleaner long-term model is for wasm2go-wasi-host to consume the official suite downstream, either as a submodule or from the dist package, as you suggested.

The basic premise of this repository is to take tests written in different source languages and compile them into wasm modules/components. IIUC the wasm2go flow is almost the inverse: take an already built wasm module, transpile it to Go, generate a wrapper project, compile that, and then run the native binary. Id be happy to see a go toolchain and go authored wasi tests in this repo, but I don't think that solves the wasm2go-run integration problem.

That said, I still think there may be value in keeping a small adapter upstream for discoverability and convenience, as long as wasm2go-run is treated as an external runner. So the testsuite only passes the wasm path, args, env, and preopened root, while wasm2go-run owns the transpile/build/execute pipeline internally.

So my suggestion would be: keep the full integration downstream, and if we want anything upstream, limit it to an adapter-only PR updated to the current runner API. WDYT?