Skip to content
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

Closed
alexcrichton opened this issue Oct 26, 2023 · 3 comments
Closed

Tracking issue for migrating to the new CLI #7384

alexcrichton opened this issue Oct 26, 2023 · 3 comments

Comments

@alexcrichton
Copy link
Member

alexcrichton commented Oct 26, 2023

Note: if you'd rather not read up on this change and deal with it later then set WASMTIME_NEW_CLI=0 to force usage of the old CLI or WASMTIME_NEW_CLI=1 to force usage of the new CLI. This environment variable will go away in the future and the old CLI will be removed. This won't happen at least until Wasmtime 16 and at this time no exact time to make this change has been determined.

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:

    wasmtime run foo.wasm --invoke bar
    

    Was parsed in the old parser as invoking the bar function of foo.wasm. In
    the new parser this parses as passing the --invoke flag to the foo.wasm
    CLI program. In this situation a warning will be issued. This example could be
    fixed by changing the order of the arguments:

    wasmtime run --invoke bar foo.wasm
    

    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:

    wasmtime run --disable-cache foo.wasm
    

    no longer works because --disable-cache was renamed to -C cache=n. This
    will 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 a
summary 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 everything
else was passed to the wasm program. This is a future compatibility hazard
though because -- is often omitted meaning that in the future it could be
difficult 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:

wasmtime run [wasmtime-flags] foo.wasm [wasm-flags]

or

wasmtime [wasmtime-flags] foo.wasm [wasm-flags]

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 now
categorized 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 example

These single-letter flags additionally have --longer names as well. Nearly
all 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

[old]$ wasmtime foo.wasm --invoke bar
[new]$ wasmtime --invoke bar foo.wasm
[old]$ wasmtime run foo.wasm --invoke bar
[new]$ wasmtime run --invoke bar foo.wasm

Renaming Wasmtime options

[old]$ wasmtime --disable-cache foo.wasm
[new]$ wasmtime -C cache=n foo.wasm
[old]$ wasmtime run --disable-cache foo.wasm
[new]$ wasmtime run -C cache=n foo.wasm

Passing flags to WebAssembly files

[old]$ wasmtime run foo.wasm -- --flag
[new]$ wasmtime run -- foo.wasm --flag

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 file

[old]$ wasmtime run foo.wasm -- --
[new]$ wasmtime run -- foo.wasm --

Note 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.

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.
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
@eminence
Copy link
Contributor

Some things to add to the TODO list, when you have a chance:

@alexcrichton
Copy link
Member Author

Thanks for the heads up! I posted #7408 to cover those. Apologies for missing the --help, I thought I went through that but I ended up missing it...

@alexcrichton
Copy link
Member Author

The old CLI was removed in #8597 and Wasmtime 22 no longer supports the old CLI

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

No branches or pull requests

2 participants