Move Spin interfaces into their own packages
Opened this issue · 2 comments
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:spin@3.0.0. (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:key-value@2.0.0, spin:sqlite@2.0.0) 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/http-trigger@3.0.0 might import spin:key-value@2.0.0 and spin:rdbms-types@3.0.0; later, fermyon:spin/http-trigger@4.0.0 might rev to spin:key-value@3.0.0 but still remain on spin:sqlite@2.0.0.
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.
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... 😅
I like the idea of doing it incrementally. I am guessing we will need to move fermyon:spin@2.0.0 into deps anyway so that the top-level package can be fermyon:spin@3.0.0, and the 3.0 package can cite unchanged interfaces a la fermyon:spin/sqlite@2.0.0. Only when we change the SQLite interface would we pull it out to its own package. Does that sound right?