Add toolchain hint heuristics on `spin new`

[lann]

Each language has its own toolchain setup requirements. Ideally we could handle these seamlessly for developers, but until we can figure that out we should try to give more guidance to reduce frustration.

The most obvious example is skipping rustup target add wasm32-wasi, which while documented in the quickstart guide is easy to miss/forget. It would be great if we could detect this situation and print a helpful message at one or more of these points:

• spin new - look for a Cargo.toml in the template?
• spin build - on failure, look for cargo.*wasm32-wasi in a component.build.command?
• spin up - on failure, look for target/wasm32-wasi in the source

In any of these cases we could use the existing check from build.rs: https://github.com/fermyon/spin/blob/60976e41231820ba6b3c4d6e0391814b459c7628/build.rs#L84-L94

[itowlson]

Cf. #629 which has discussion of possible approaches and challenges

[radu-matei]

I really like that right now, no parts of Spin currently have to care about the source of the Wasm components.

Adding something like this in spin build and spin up would require us to do this, and moreover, to keep the checks (and messages) in sync for... ever?

For example, if our message for Go talks about TinyGo, and we want to switch the templates to use the official Go toolchain, that requires a Spin release as well, since the message would now be out of date.

If we there is no way around this, then teaching Spin itself about language toolchains is... fine.
Before going there, is there anything we can do on the templates?

Build scripts, makefiles, combination of both?

[itowlson]

I did some experimenting with this as part of #629, and putting the prerequisites knowledge into the manifest, e.g. a component.build.checks section, got very hairy (it looked like it would turn into some crazy DSL for expressing prerequisites, at which point I made my excuses). Putting the checks / error handlers into a makefile is more practical, but introduces a new tool (probably not an issue for most Spin developers, but definitely a speed bump for Windows folks). It also kind of raises the question of if spin build just runs make then why would I not run the shorter command! grin

[michelleN]

Is this still something we want to explore? How should we think about this in relation to spin doctor? Do we consider this issue a duplicate of #629

[lann]

spin doctor does check for this now; running that after spin new might be a reasonable approach?

[michelleN]

@lann do you think we should run spin doctor after new by default and have the be a flag one can turn off/on?

[lann]

Not sure what the UX should be exactly. It would be a little annoying today because one of the spin doctor checks will immediately suggest that you spin build. We could pick a subset of checks to run or teach checks to filter themselves by context, like "don't run me on spin new".

[itowlson]

cf. #1532 which was intended to work towards this scenario (though had not been refined in terms of the use cases)