fermyon
Spin Build Targets Check SIP
I was thinking a bit more about the custom triggers thing, and wanted to take a moment to align our understandings.
For me, the main value of this work is kind of a technology proof for validating against a world once we have a world (or, more broadly, a set of acceptable worlds). That's a prerequisite for target environments, but there's a whole lot of additional work in defining what an environment is and how we understand it. Again consider the "I want to target SpinKube 3.2" scenario. SpinKube 3.2 isn't a world: it's a mapping of trigger types to worlds. We will need to understand from some source what that mapping is.
The custom triggers discussion seems to cross over into the "understand the environment / mapping" problem, but in a way that is very specific to the "the version of Spin I am running here and now" environment. Yes, we want to be able to validate for that local environment for sure. But I'm wondering if we should punt on solving the mapping problem for that "local Spin" environment until we can consider it alongside other environments.
As I say, that's just my envisioned purpose and scope for this leg of the work. It may be (it seems likely) that other folks have a different vision and scope, so I'd like to crisp up what that is and how it fits into the eventual goal.
But I'm wondering if we should punt on solving the mapping problem for that "local Spin" environment until we can consider it alongside other environments.
I would be fine with us making the decision to hold off on solving this for custom triggers (for now) until we firm up our longer term goals (those of which are still not entirely clear to me at the moment).
I would also be aligned to solving this for the set of known worlds and not tackle custom triggers and worlds in the first go.
@radu-matei Thanks. I have a technology POC that uses the wac libraries to validate a component or module against the HTTP target world. The trouble is that wac currently only validates matching exports, not matching imports (see https://github.com/bytecodealliance/wac/issues/127). Now there is an alternative, to use wasm-tools component targets, which does verify imports but... which doesn't produce useful error messages on validation failure.
Now, we can and will invest in those upstream projects to improve this - but at the moment, @fibonacci1729 is on point for that, and he is also trying to land component dependencies in Spin. Given that, and that component dependencies will affect how target validation works, the current proposal was for him to prioritise component dependencies, then resume the upstream and target worlds stuff.
@fibonacci1729 hope this is an accurate representation of the current thinking - please correct me if not!
@fibonacci1729 Is this superseded by #3217? It seems like they cover the same feature but I may be misunderstanding!