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-exampleVersions and Environment
Wasmtime version or commit: 15.0.1
Operating system: Linux
Architecture: amd64
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 tofoo.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 casearg
). The new CLI updates this to stop feeding options to Wasmtime after--
or after the first positional argument (in this casefoo.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
tostrace
, it passes it tols
). 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.
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)
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: Dec 23 2024 at 13:07 UTC