Seems the docker platform is backwards?

[codefromthecrypt]

Describe the bug

It seems the docker plaform for wasm is specified in the opposite fashion as other docker platforms.

e.g.

$ docker build \
  --platform=wasm32/wasi \
  -f tmp/Dockerfile.emojize \
  -t emojize.py-wasm .

Typically, it is the other way around, right?, e.g. 'linux/amd64' not 'amd64/linux' https://docs.docker.com/build/building/multi-platform/

Reproduction steps

https://github.com/vmware-labs/webassembly-language-runtimes/blob/2b5e224aec627677be837d93e5116d9472f4f5cc/python/examples/run_all_snippets.sh#L80

Expected behavior

I would expect the platform in normal docker order, as some tools split on this.. e.g. wasi/wasm32 not wasm32/wasi

Additional context

p.s. in Go, the platform is wasm not wasm32 and the OS is wasip1 not wasi, so this is a more rare case of drift between docker and go norms also.

[codefromthecrypt]

ps if this is possible to change, I would do so including the os component to "wasip1". I suspect since the order is backwards also, any change could consider adjusting both parts, or at least the OS part.

Historically, people used "wasi" maybe under the idea that it would be compatible over time. Starting with preview 2, wasi is very much and intentionally incompatible. Through a long discussion with many different folks, Golang settled on "wasip1" for the preview/snapshot1 imports. They could because there was no historical reason to do otherwise, so in a rare position of being able to fix the glitch before people did too much. See https://github.com/golang/go/issues/58141 for more context.

[assambar]

Thanks a lot @codefromthecrypt! We will discuss if we can reuse the wasip1 approach that GO does, then we'll fix our images and examples!

[codefromthecrypt]

@assambar thanks. I can imagine the near term need/use of a multi-platform image (e.g. wasip1 and wasip2). that way you can tell which might run before pulling the layers, similar to how normal docker platform works.

[assambar]

As a short term, I will update the container platform to wasi/wasm32 for the next Python release, as this is what most people are still used to. We will probably re-publish as wasip1/wasm32 when preview2 is about to come.

[codefromthecrypt]

thanks, meanwhile I corrected some tooling to ignore the platform. There are worse platforms btw, for example the instructions some use for proxy-wasm will default to the current platform! https://github.com/solo-io/wasm/blob/master/spec/spec-compat.md#appendix-2-build-a-compat-image-with-docker-cli

[assambar]

Fixed with wasi/wasm32 only for new (python-wasm:3.11.3) images.

[codefromthecrypt]

thanks!