Stream: wasmtime

Topic: Upcoming changes to Wasmtime's CLI


view this post on Zulip Alex Crichton (Aug 31 2023 at 19:45):

I wanted to start a stream on Zulip about the upcoming changes to Wasmtime's CLI. This is here to serve a few purposes:

We talked a fair bit about upcoming changes to Wasmtime's CLI in the meeting today and the conclusion was that we're going to try to communicate these changes broadly and prepare everyone for them since it's likely to break almost all users of the CLI. The current planned release date for these changes is Wasmtie 14.0.0 on October 20.

The two major changes being implemented are:

Also there's a bit of history here so despite the first PR looking merged it's not actually since it's now been reverted for the 13.0.0 release. This means that, at this time, there is no build available that has these changes merged in which folks can provide feedback on. At this stage this is mostly "blast out the information" and gathering feedback if users have concerns before moving forward.

My current plan is to land both of these changes, pending approvals, on or around September 11 which is the first Monday after WasmCon. This will be on the main branch which will get released as Wasmtime 14.0.0 in October and additionally will intentionally miss creation of the release-13.0.0 branch happening on September 5.

Once these two changes are landed in main I'll post a notification here since there will be builds to download and play around with for interested users. Additionally I hope to write up more long-form information at least in the form of release notes and possibly more information here too.

If anyone has thoughts or concerns though please post here!

This commit is a partial revert of #6737. That change was reverted in #6830 for the 12.0.0 release of Wasmtime and otherwise it's currently slated to get released with the 13.0.0 release of Wasmtim...
Currently the way we've configured argument parsing it's valid to execute a command such as: wasmtime run foo.wasm -O which is the same as: wasmtime run -O foo.wasm or otherwise all flags are att...
This commit follows through on discussion from #6741 to redesign the flags that the wasmtime binary accepts on the CLI. Almost all flags have been renamed/moved and will require callers to update. ...

view this post on Zulip Alex Crichton (Aug 31 2023 at 19:46):

I'd also like to point out and clarify that this is probably the last major refactor we're going to get to do of Wasmtime's CLI for quite some time, so I'd like to ideally handle as much as possible in terms of concerns!

Consequently if you have any wishes/concerns/etc about Wasmtime's CLI please bring them up! This is a perfect time to bikeshed and figure out everything since it's gonna be much harder to do this the next time around.

view this post on Zulip Alex Crichton (Aug 31 2023 at 20:04):

I've opened https://github.com/bytecodealliance/wasmtime/pull/6946 now as a PR to land for requiring Wasmtime's options come first, meaning the intent is to land that and https://github.com/bytecodealliance/wasmtime/pull/6925 on or around September 11.

This commit implements a new behavior for the CLI of the wasmtime executable which will require that options for Wasmtime itself come before the wasm module being run. Currently they're allowed to ...
This commit follows through on discussion from #6741 to redesign the flags that the wasmtime binary accepts on the CLI. Almost all flags have been renamed/moved and will require callers to update. ...

view this post on Zulip Alex Crichton (Sep 13 2023 at 21:54):

Ok both PRs have now landed. This means that the dev releases, and for anyone contributing to main, the CLI of Wasmtime is now different. Please feel free to kick the tires, report issues, and otherwise provide feedback here or through GitHub!

view this post on Zulip Alex Crichton (Sep 13 2023 at 21:54):

If anything feels weird or feels like it could be better I'm also keen to hear about it

view this post on Zulip Alex Crichton (Sep 13 2023 at 22:52):

Oh also, as a reminder, these changes won't get released until October 20. This means that Wasmtime 12, the current release, is not affected. Additionally the Wasmtime 13 release next week will also be unaffected. They continue to use the old CLI and its conventions

view this post on Zulip Alex Crichton (Oct 19 2023 at 15:58):

Heads up on this one final time to continue to spread awareness, the 14.0.0 release is just around the corner (tomorrow!) and these CLI changes will be included in them. Now's the best time for any final feedback, concerns, or changes

view this post on Zulip Brett Cannon (Oct 19 2023 at 18:48):

FYI I did a survey of WASI runtimes and their CLIs to see if there's any commonality (answer is "no"). The proposed --dir=local::guest gets the flag to match wasmedge, but the path separator will be different. Wasmer matches the current/soon-to-be-old --mapdir=local::guest format (wazero uses --mount, so is completely different).

view this post on Zulip Alex Crichton (Oct 19 2023 at 19:01):

Thanks! One difference I know Wasmtime has is that it does GUEST::HOST which I know additionally differs from Docker and reminds me that I've wanted to change that, so I'll go push that through.

As for :: vs :, I wasn't around when this was originally implemented but if I had to guess it's to handle C:\... for Windows paths where : shows up there but not on unix, and :: is a little less ambiguous

view this post on Zulip Alex Crichton (Oct 19 2023 at 22:42):

oops lost track of this but here's a PR for swapping the order

This commit changes the --dir argument on the wasmtime CLI to be HOST::GUEST rather than GUEST::HOST. This matches Docker for example and is a little more consistent with only --dir path where the ...

Last updated: Dec 23 2024 at 13:07 UTC