-
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
Tracking issue for migrating to the new CLI #7384
Comments
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Oct 26, 2023
This commit introduces a compatibility shim for the Wasmtime 13 CLI and prior. The goal of this commit is to address concerns raised in bytecodealliance#7336 and other locations as well. While the new CLI cannot be un-shipped at this point this PR attempts to ameliorate the situation somewhat through a few avenues: * A complete copy of the old CLI parser is now included in `wasmtime` by default. * The `WASMTIME_NEW_CLI=0` environment variable can force usage of the old CLI parser for the `run` and `compile` commands. * The `WASMTIME_NEW_CLI=1` environment variable can force usage of the new CLI parser. * Otherwise both the old and the new CLI parser are executed. Depending on the result one is selected to be executed, possibly with a warning printed. * If both CLI parsers succeed but produce the same result, then no warning is emitted and execution continues as usual. * If both CLI parsers succeed but produce different results then a warning is emitted indicating this. The warning points to bytecodealliance#7384 which has further examples of how to squash the warning. The warning also mentions the above env var to turn the warning off. In this situation the old semantics are used at this time instead of the new semantics. It's intended that eventually this will change in the future. * If the new CLI succeeds and the old CLI fails then the new semantics are executed without warning. * If the old CLI succeeds and the new CLI fails then a warning is issued and the old semantics are used. * If both the old and the new CLI fail to parse then the error message for the new CLI is emitted. Note that this doesn't add up to a perfect transition. The hope is that most of the major cases of change at the very least have something printed. My plan is to land this on `main` and then backport it to the 14.0.0 branch as a 14.0.3 release.
This was referenced Oct 26, 2023
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 28, 2023
* Add compatibility shims for Wasmtime 13 CLI This commit introduces a compatibility shim for the Wasmtime 13 CLI and prior. The goal of this commit is to address concerns raised in #7336 and other locations as well. While the new CLI cannot be un-shipped at this point this PR attempts to ameliorate the situation somewhat through a few avenues: * A complete copy of the old CLI parser is now included in `wasmtime` by default. * The `WASMTIME_NEW_CLI=0` environment variable can force usage of the old CLI parser for the `run` and `compile` commands. * The `WASMTIME_NEW_CLI=1` environment variable can force usage of the new CLI parser. * Otherwise both the old and the new CLI parser are executed. Depending on the result one is selected to be executed, possibly with a warning printed. * If both CLI parsers succeed but produce the same result, then no warning is emitted and execution continues as usual. * If both CLI parsers succeed but produce different results then a warning is emitted indicating this. The warning points to #7384 which has further examples of how to squash the warning. The warning also mentions the above env var to turn the warning off. In this situation the old semantics are used at this time instead of the new semantics. It's intended that eventually this will change in the future. * If the new CLI succeeds and the old CLI fails then the new semantics are executed without warning. * If the old CLI succeeds and the new CLI fails then a warning is issued and the old semantics are used. * If both the old and the new CLI fail to parse then the error message for the new CLI is emitted. Note that this doesn't add up to a perfect transition. The hope is that most of the major cases of change at the very least have something printed. My plan is to land this on `main` and then backport it to the 14.0.0 branch as a 14.0.3 release. * Wordsmith messages * Update messages * More wording updates * Fix grammar * More updates
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Oct 28, 2023
* Add compatibility shims for Wasmtime 13 CLI This commit introduces a compatibility shim for the Wasmtime 13 CLI and prior. The goal of this commit is to address concerns raised in bytecodealliance#7336 and other locations as well. While the new CLI cannot be un-shipped at this point this PR attempts to ameliorate the situation somewhat through a few avenues: * A complete copy of the old CLI parser is now included in `wasmtime` by default. * The `WASMTIME_NEW_CLI=0` environment variable can force usage of the old CLI parser for the `run` and `compile` commands. * The `WASMTIME_NEW_CLI=1` environment variable can force usage of the new CLI parser. * Otherwise both the old and the new CLI parser are executed. Depending on the result one is selected to be executed, possibly with a warning printed. * If both CLI parsers succeed but produce the same result, then no warning is emitted and execution continues as usual. * If both CLI parsers succeed but produce different results then a warning is emitted indicating this. The warning points to bytecodealliance#7384 which has further examples of how to squash the warning. The warning also mentions the above env var to turn the warning off. In this situation the old semantics are used at this time instead of the new semantics. It's intended that eventually this will change in the future. * If the new CLI succeeds and the old CLI fails then the new semantics are executed without warning. * If the old CLI succeeds and the new CLI fails then a warning is issued and the old semantics are used. * If both the old and the new CLI fail to parse then the error message for the new CLI is emitted. Note that this doesn't add up to a perfect transition. The hope is that most of the major cases of change at the very least have something printed. My plan is to land this on `main` and then backport it to the 14.0.0 branch as a 14.0.3 release. * Wordsmith messages * Update messages * More wording updates * Fix grammar * More updates
alexcrichton
added a commit
that referenced
this issue
Oct 28, 2023
* Add compatibility shims for Wasmtime 13 CLI This commit introduces a compatibility shim for the Wasmtime 13 CLI and prior. The goal of this commit is to address concerns raised in #7336 and other locations as well. While the new CLI cannot be un-shipped at this point this PR attempts to ameliorate the situation somewhat through a few avenues: * A complete copy of the old CLI parser is now included in `wasmtime` by default. * The `WASMTIME_NEW_CLI=0` environment variable can force usage of the old CLI parser for the `run` and `compile` commands. * The `WASMTIME_NEW_CLI=1` environment variable can force usage of the new CLI parser. * Otherwise both the old and the new CLI parser are executed. Depending on the result one is selected to be executed, possibly with a warning printed. * If both CLI parsers succeed but produce the same result, then no warning is emitted and execution continues as usual. * If both CLI parsers succeed but produce different results then a warning is emitted indicating this. The warning points to #7384 which has further examples of how to squash the warning. The warning also mentions the above env var to turn the warning off. In this situation the old semantics are used at this time instead of the new semantics. It's intended that eventually this will change in the future. * If the new CLI succeeds and the old CLI fails then the new semantics are executed without warning. * If the old CLI succeeds and the new CLI fails then a warning is issued and the old semantics are used. * If both the old and the new CLI fail to parse then the error message for the new CLI is emitted. Note that this doesn't add up to a perfect transition. The hope is that most of the major cases of change at the very least have something printed. My plan is to land this on `main` and then backport it to the 14.0.0 branch as a 14.0.3 release. * Wordsmith messages * Update messages * More wording updates * Fix grammar * More updates
Some things to add to the TODO list, when you have a chance:
|
Thanks for the heads up! I posted #7408 to cover those. Apologies for missing the |
2 tasks
The old CLI was removed in #8597 and Wasmtime 22 no longer supports the old CLI |
alexrp
added a commit
to alexrp/zig
that referenced
this issue
Jul 22, 2024
alexrp
added a commit
to alexrp/zig
that referenced
this issue
Jul 23, 2024
andrewrk
pushed a commit
to ziglang/zig
that referenced
this issue
Jul 23, 2024
SammyJames
pushed a commit
to SammyJames/zig
that referenced
this issue
Aug 7, 2024
igor84
pushed a commit
to igor84/zig
that referenced
this issue
Aug 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm opening this as a tracking issue to assist users in migrating from the old
Wasmtime 13-and-prior CLI to the new Wasmtime 14-and-later CLI. Wasmtime 14.0.x
is going to receive a patch update which restores support for the old CLI to
simultaneously support both the old and the new. The support, however, will
issue warnings that point to this issue. Specifically:
If a CLI invocation parses different in Wasmtime 13 ("the old") and Wasmtime
14 ("the new") then a warning is issued. For example:
Was parsed in the old parser as invoking the
bar
function offoo.wasm
. Inthe new parser this parses as passing the
--invoke
flag to thefoo.wasm
CLI program. In this situation a warning will be issued. This example could be
fixed by changing the order of the arguments:
which will no longer emit a warning.
CLI invocations which fail to parse in the new parser but succeed in the old
parser will continue to work but emit a warning. For example:
no longer works because
--disable-cache
was renamed to-C cache=n
. Thiswill continue to work through but emit a warning.
This issue is being filed as I'm going to hardcode in the source code a print
of a warning which points here for users to find and discuss. My hope is to
incorporate feedback here into future iterations of the warning and/or the CLI.
Changes in Wasmtime 14
In Wasmtime 14 the
wasmtime
executable CLI syntax changed. #6925 has asummary of the changes as well as a detailed table to renamed flags, but a
summary is restated here as well.
Parsing Changes
The first major change in Wasmtime 14 was a change to how arguments are parsed
to Wasmtime vs the WebAssembly program being run. Previously Wasmtime would
parse arguments anywhere before a
--
on the CLI as its own, and everythingelse was passed to the wasm program. This is a future compatibility hazard
though because
--
is often omitted meaning that in the future it could bedifficult for Wasmtime to add new CLI options as they would shadow any matching
option passed to wasm itself.
Instead, starting in Wasmtime 14, all flags to Wasmtime must happen between the
wasmtime
subcommand and the WebAssembly program being run. For example:or
Syntax Changes
The second major change in Wasmtime 14 was a change to the syntax of how many
arguments are passed. The Wasmtime CLI had previously organically grown where
options were inconsistently named and surfaced. This ended up with a sprawling
--help
page as well differences between option names. Options are nowcategorized into five broad categories:
-O foo
- an optimization or performance-tuning related option-C foo
- a codegen option affecting the compilation process.-D foo
- a debug-related option-W foo
- a wasm-related option, for example changing wasm semantics-S foo
- a WASI-related option, configuring various proposals for exampleThese single-letter flags additionally have
--longer
names as well. Nearlyall configuration and tuning options for Wasmtime are now housed behind one of
these flags. Each flag can be explored with
wasmtime -O help
for example.Examples of handling warnings
This section is intended to list a suite of old CLI invocations and their
equivalent in the new CLI. Where possible a new command is listed which parses
the same both under the old CLI and the new CLI.
Moving Wasmtime options before the WebAssembly file
Renaming Wasmtime options
Passing flags to WebAssembly files
Note that the new CLI also accepts
wasmtime run foo.wasm --flag
but the old CLI does not accept this. Additionally this will print a warning while the old CLI is still supported.Passing
--
to a wasm fileNote that the new CLI also accepts
wasmtime run foo.wasm --
but the old CLI does not accept this. Additionally this will print a warning while the old CLI is still supported.The text was updated successfully, but these errors were encountered: