Remove special guidance around wasm

[imjasonh]

Go is going to support a platform like wasip1/wasm, wasip2/wasm, and eventually wasi/wasm. We should remove the guidance that Wasm is a special case, and fallback to following Go's guidance when describing a platform.

Fixes #1053

This exception was added in #964 -- see there for original (outdated!) discussion.

[imjasonh]

A noteworthy excerpt of the PR that added it:

Diverging from Go here provides some small opportunity for trouble for us down the road:

• Go could add official support for WASI, but choose to do so using a GOOS value that isn't wasi -- this would confuse our guidance more, since there'd be a valid GOOS for WASI that isn't our recommended .platform.os value.

...
Either of these scenarios seem unlikely, and we'd have some options in either case to avoid confusion. Trying to plan for infinite scary futures is hard.

Well, that's what happened! Let's back it out before we cut v1.1 so we're not stuck with this decision any longer than necessary.

[tianon]

Go is going to support a platform like wasm/wasip1, wasm/wasip2, and eventually wasm/wasi. We should remove the guidance that Wasm is a special case, and fallback to following Go's guidance when describing a platform.

Scratch that, reverse it (wasi is the os value, not the arch value) 😅

Go is going to support a platform like wasip1/wasm, wasip2/wasm, and eventually wasi/wasm. We should remove the guidance that Wasm is a special case, and fallback to following Go's guidance when describing a platform.

I'd like to solicit comments from @rumpl, who has done a lot of work on container runtimes (moby/moby engine maintainer) and WASM/WASI, since I think he's got a somewhat unique perspective with a good amount of experience in both halves of this. 🙇 ❤️

I also think #964 (comment) is worth revisiting, specifically whether we should consider using os.version for this (which Go doesn't have an analogue for that I'm aware of, so they couldn't have considered using it) -- it's hard to say what the future of wasi or wasm holds, but I'm guessing this isn't going to be the last time we have incompatibilities between builds and which versions runtimes can reasonably support. 😞

[imjasonh]

Scratch that, reverse it (wasi is the os value, not the arch value) 😅

Thank you for pointing this out! I'll update the original comment to avoid any (more) confusion.

I also think #964 (comment) is worth revisiting, specifically whether we should consider using os.version for this (which Go doesn't have an analogue for that I'm aware of, so they couldn't have considered using it) -- it's hard to say what the future of wasi or wasm holds, but I'm guessing this isn't going to be the last time we have incompatibilities between builds and which versions runtimes can reasonably support. 😞

I think it's simplest to say "just follow Go's precedent" for as long as we can, until there's some case where Go's semantics don't support what the OCI community needs. This very nearly happened with Wasm, and I think our response to it was good. Little did I realize that Go would leap back into action and catch up and surpass us. 😆

So I think wasip1/wasm is better than wasi/wasm-with-os.version=p1, because we can still just follow Go's lead, and the rules are relatively simpler.

If/when in the future some incompatibility comes up where Go precedent doesn't satisfy OCI's needs, we can carve out another exemption, or say "for os=newthing, follow $otherlang's platform semantics," which may involve leveraging os.version (or variant, or a new field we specify, who knows)

[codefromthecrypt]

FWIW wasip1/wasm was the result of a sensible deliberation amongst a lot of different people. It wasn't random or not thought through, and it was made knowing about the existing "wasi" conventions and the problems with it. There are a growing number on 👍 this PR because it makes sense and fits into existing tool work. We really don't want a world of preventable "if statements" in Makefiles etc. Thanks for raising this!