Move Spin interfaces into their own packages

[itowlson]

As part of Spin 3, we hope to add new interfaces (e.g. wasi:keyvalue/store) and possibly modify some existing ones (e.g. rdbms-types). So we are likely to need to define new worlds and it seems plausible that they will need to go in a new package version, e.g. fermyon:[email protected]. (Please consider this assumption open to challenge. I am not confident in how this stuff fits together.)

At the moment, all our interfaces (e.g. key-value, sqlite, mysql) are in the fermyon:spin package, meaning they must be versioned together. However, many of these interfaces will not change. This is a pattern we're likely to see again and again over time.

We should consider moving each interface into its own package (e.g. spin:[email protected], spin:[email protected]) and having the top-level fermyon:spin package and worlds import these as dependencies. This would allow interfaces to be revved independently instead of as a big bang. Thus fermyon:spin/[email protected] might import spin:[email protected] and spin:[email protected]; later, fermyon:spin/[email protected] might rev to spin:[email protected] but still remain on spin:[email protected].

This could also help with modularising SDKs as distinct packages could be pulled in by direct references.

The initial move would be a larger change but the hope is that this would allow us to make smaller and more granular changes in future, and to treat Spin APIs in a similar way to externally defined APIs such as wasi-cloud-core.

[lann]

A slight variation to consider here would be to only rename (re-package?) those interfaces that are actually getting breaking changes. While this would make things less consistent, it would also avoid a bunch of boilerplate code like needing to implement identical fermyon:spin/http and spin:http/outbound (?) interfaces. As I type that, it occurs to me that it would also avoid needing to come up with some interface names... :sweat_smile:

[itowlson]

I like the idea of doing it incrementally. I am guessing we will need to move fermyon:[email protected] into deps anyway so that the top-level package can be fermyon:[email protected], and the 3.0 package can cite unchanged interfaces a la fermyon:spin/[email protected]. Only when we change the SQLite interface would we pull it out to its own package. Does that sound right?

[itowlson]

This is pretty much what we have been doing so welcome to closeville