Spin 3 world

[itowlson]

This is based on conversations with @tschneidereit and @alexcrichton. It's broken into two commits so we can look at (some) different approaches.

Note: this includes the wasi-config PR because I wanted to validate the requirement of "something that is in the Spin 3 world but not in Spin 2." In reality the wasi-config PR should be on top of this and not the other way round! This now contains only the existing interfaces. I'll rebase wasi-config and wasi-keyvalue onto this with their interfaces in the shiny new world.

The first approach (seen in the first commit) is:

• Move all fermyon:[email protected] stuff - worlds and interfaces - into deps.
• Create a new fermyon:[email protected] package with worlds that reference the interfaces from the @2.0.0 package, as well as others such as wasi-http and wasi-config.
• If we make changes to Spin API interfaces (e.g. new types in RDBMS interfaces), then these will go in their own package in deps (e.g. spin:[email protected]) and be referenced from the 3.0.0 worlds. (Otherwise we continue to use the Spin 2 interfaces.)

Why not rev the Spin API interfaces and have 3.0.0 be self-contained? The answer is twofold. First, implementing those parallel identical interfaces takes time and adds code, but adds no value. Nothing has changed, why change anything. Second, Spin is going to be heterogeneous anyway. We already have wasi-http, we will have wasi-config and wasi-keyvalue, at some point wasi-blobstore. We will never be able to lockstep versions: external dependencies will rev separately at their own pace. We may as well embrace that and let our own APIs rev independently. We don't want to have to issue a whole new set of Spin API interfaces every time a single one revs.

The second commit goes further, and I am not quite sure how to do this right (this was a suggestion from Alex which I really like but haven't figured out yet):

• Move the fermyon:[email protected] worlds into deps. (As noted, it is proposed that there are no fermyon:[email protected] interfaces.)
  • The idea here is that the 2, 3, 4, etc. worlds are all on a par. There's no sense of privileging the latest world by storing it at the top level, then gets demoting it to a dep when the hot new world comes along.
• Create a new top-level package which brings in the Spin 2 and 3 worlds by reference. This is the bit I'm not clear on. The current top-level package is a placeholder. It seems to compile, but the version is clearly wrong, and the fact that it doesn't reference anything seems super weird. This uses the name spin:top-level (unversioned) because the package itself does nothing and should never be referenced, it is just a feeble excuse to rope in a big bag o' deps (and all those are versioned). @alexcrichton I'd value getting your eyes on this!

Note this does not tackle any SDK considerations around switching worlds, but existing SDKs (and binaries) should still work because the Spin 2 interfaces remain fully supported.

[itowlson]

Looks like the empty package breaks the way test bindings are generated for a start... Fixed. I updated the tests to use the WASIp2 world instead of the RC world.

[alexcrichton]

Looks good to me!

[alexcrichton]

One option for this might be to remove most of this and instead just have include fermyon:spin/[email protected]; perhaps? (to clearly indicate it's inheriting from a historical version with other additions to come in the future)