-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change wasmtime serve
to apply -S common
by default
#8086
Comments
The reason this wasn't done by default originally was because it was seen as desirable to have Given that I'd personally see two possible routes from here:
If possible I think it'd be good to hold the line where |
I agree that in principle it'd be good to keep this minimal. I'm not convinced that we'll be able to provide a developer experience here that'll not have people continue to run into roadblocks immediately. Yes, we can make those roadblocks easier to understand (and should, independently, of this particular issue!) I think there are two things making this challenging to address: one is that perhaps the reality is that most use cases really do want more of WASI for running a server than is currently contained in If we can't solve this, then that to me indicates that we should make |
To clarify though I'm not arguing for minimality, I agree that we should turn My point is that adding Or perhaps put another way, can you expand a bit more on why you think it's ok |
Yeah, that is a great question, and I agree that it needs an answer if we want to change anything here (that doesn't involve changes to My take is twofold: one part is very pragmatically that, as mentioned above, it's very difficult right now to target a pure The second part is that I guess more generally I'm in this case not too concerned about the availability of more functionality leading developers to expect those to be available in all environments implementing |
Reading over WebAssembly/wasi-http#79 again I think I'm probably the only one advocating for |
This commit enables more WASI interfaces by default with `wasmtime serve`, notably through the use of the `-Scommon` flag. This means that the interfaces supported by `wasmtime serve` are the same as `wasmtime run` by default. To fully implement this there's a number of refactorings here: * More flags like `--dir` and `--env` are moved into `RunCommon` to be shared between `wasmtime serve` and `wasmtime run`, meaning that the `serve` command can now configure environment variables. * A small test has been added as well as infrastructure for running tests with `wasmtime serve` itself. Previously there were no tests that executed `wasmtime serve`. * The `test_programs` crate had a small refactoring to avoid double-generation of http bindings. Closes bytecodealliance#8086
This commit enables more WASI interfaces by default with `wasmtime serve`, notably through the use of the `-Scommon` flag. This means that the interfaces supported by `wasmtime serve` are the same as `wasmtime run` by default. To fully implement this there's a number of refactorings here: * More flags like `--dir` and `--env` are moved into `RunCommon` to be shared between `wasmtime serve` and `wasmtime run`, meaning that the `serve` command can now configure environment variables. * A small test has been added as well as infrastructure for running tests with `wasmtime serve` itself. Previously there were no tests that executed `wasmtime serve`. * The `test_programs` crate had a small refactoring to avoid double-generation of http bindings. Closes bytecodealliance#8086
Thinking about this more, it seems desirable to avoid a situation where filesystems/sockets come to be seen as "common" functionality that's implicitly included in everything. One potential problem here is that Another potential problem is that Even with the rename, and even if we provide finer-grained flags, there still a question of, what do we want the proxy world to be? And, if we start bundling files/sockets/etc. with it by default, will it be harder in the future t disable it by default again, if we improve the ergonomics and want to start promoting platforms based on the proxy world? What if we added a diagnostic to wasmtime for when a program has unsatisfied imports that suggests users add |
I think having that would to some degree alleviate my concerns here. I'm not sure it would have all that much value though: I'm skeptical that users would take much more away from this than "oh ok, I guess the way to run these things in the Wasmtime CLI involves adding I also don't really think that |
For example, on crates.io dependencies can include their own wit-bindgen bindings, which then get silently added to the implied world of the final component. It's possible for developers to pick up additional component-model-level dependencies without being aware of it. If we want to have small and simple works like wasi-http's |
People keep running into problems with
wasmtime serve
because by default it only exposeswasi:proxy
, nothing else. I think we should change the behavior here to imply-S common
to make default toolchains and in particular the normal Preview1 adapter work.One could see it as a downside that
wasmtime serve
would be a bit less specifically about HTTP, but I can't really come up with compelling arguments for why that'd be a problem.The text was updated successfully, but these errors were encountered: