Stream: git-wasmtime

Topic: wasmtime / issue #7695 flag/option ordering matters in th...

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 18:57):

brendandburns edited issue #7695:

@brendandburns ➜ /workspaces/dev-wasm-go (main) $ WASMTIME_NEW_CLI=1 wasmtime main.wasm --dir=.::.
Hello Go World!
Error writing open test.txt: errno 76
@brendandburns ➜ /workspaces/dev-wasm-go (main) $ WASMTIME_NEW_CLI=0 wasmtime main.wasm --dir=.
Hello Go World!
Wrote file
Copied file

Note that with the old CLI the wasm program works, with the new CLI it doesn't. I'm not sure if this is on purpose, but if it is what is the correct new syntax?

Test Case

WASM file uploaded. If you want to rebuild see:
https://github.com/dev-wasm/dev-wasm-go?tab=readme-ov-file#simple-example

Versions and Environment

Wasmtime version or commit: 15.0.1

Operating system: Linux

Architecture: amd64

main.zip

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 19:12):

alexcrichton commented on issue #7695:

The ordering of arguments with Wasmtime has always mattered, both before and after the CLI refactor. For example in the old CLI wasmtime foo.wasm arg --dir . does not work because --dir is interpreted as an argument to foo.wasm, not Wasmtime. The reason for this is that the old CLI would stop feeding options to Wasmtime after -- or after the second positional argument (in this case arg). The new CLI updates this to stop feeding options to Wasmtime after -- or after the first positional argument (in this case foo.wasm). That's why the new CLI doesn't work with the command above and why the old CLI does.

When taken literally I see how it can be concluded that Wasmtime violates the guideline that you have mentioned. Despite this though the CLI changes were done to make Wasmtime more consistent with all other tools that I at least personally know about within the space of "execute a sub-program" (e.g. docker, strace, cargo, etc). All of those commands stop feeding options to the source program after the first positional argument (e.g. strace ls -l doesn't pass -l to strace, it passes it to ls). Wasmtime is now consistently following the same semantics where it stops parsing options after the first positional argument (which for Wasmtime is always the *.wasm file to execute).

Taken a little less literally Wasmtime is not violating the guideline you highlighted. Wasmtime's option parser produces the same result no matter what order Wasmtime's own flags are passed in. For example --allow-precompiled --dir . is parsed the same way as --dir . --allow-precompiled. I say "taken less literally" here because it still requires all of Wasmtime's own options to come before the first positional argument, the *.wasm file.

Regardless though the behavior you're seeing in this issue is intended and there's not currently a bug that I'm at least personally aware of, and the issue can be fixed by passing Wasmtime's own arguments before the *.wasm for both the old and the new CLI.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 19:18):

brendandburns commented on issue #7695:

fwiw, imho the docker behavior is a bad design also. Docker explicitly introduced the -- operator into it's CLI to help correct the (bad) decisions they had previously made.

If you are looking for a counter example kubectl and practically every other standard unix command line tool does not behave this way.

Clearly I'm not in a position to force any changes in the wasmtime interpretation of the command line, but I do believe (strongly) that you are violating the principal of least surprise for the majority of users who will use your tool (and be confused when it behaves differently with different CLI ordering)

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2023 at 19:20):

brendandburns edited a comment on issue #7695:

fwiw, imho the docker behavior is a bad design also. ~Docker explicitly introduced the -- operator into it's CLI to help correct the (bad) decisions they had previously made.~

I should have said kubectl explicitly introduced the -- operator into it's CLI to help correct the (bad) decisions they had previously made (to match docker)

If you are looking for a counter example kubectl and practically every other standard unix command line tool does not behave this way.

Clearly I'm not in a position to force any changes in the wasmtime interpretation of the command line, but I do believe (strongly) that you are violating the principal of least surprise for the majority of users who will use your tool (and be confused when it behaves differently with different CLI ordering)

Last updated: Nov 22 2024 at 16:03 UTC