Where do we document template dependencies?

[technosophos]

The Rust template requires the wasm32-wasi target. The Go templates require TinyGo. Where do we document these requirements? Specifically, say a developer does this:

$ spin templates list
# sees some templates, chooses one they've never used before
$ spin new http-go myapp
$ spin build

The build will fail if TinyGo is not installed. What does the user then do to figure out why the build failed?

[technosophos]

I'm asking specifically because #628 requires that a user install SwiftWasm >= 5.5.0, and I don't know where to document that requirement.

[radu-matei]

We've been using https://spin.fermyon.dev/other-languages/ as the place to document languages we don't have a dedicated SDK for.
(source in https://github.com/fermyon/spin/blob/main/docs/content/other-languages.md)

[technosophos]

The assumption, then, is that if the user has a local build failure, they'll go to spin.fermyon.dev and try to find an answer? Would it be easier/preferable to add a BUILD.txt or some similarly standard text file that tells people what is necessary for a successful build?

[itowlson]

I like that idea.

Another idea is to provide a prerequisites section which would be a bunch of command lines that need to 'pass' (for some value of 'pass') or it would print a message saying "you need X." But that feels risky because a malicious template author could include command lines that deleted, corrupted or exfiltrated customer data.

[technosophos]

I do like the idea of prerequisites. And I am not sure it's any riskier than the build command (which could equally be hijacked to do dastardly deeds)

[lann]

Or simpler: some kind of notes field that will just be printed on template instantiation. At least for our templates we could point at TinyGo et al there.

[itowlson]

Thinking more about this... this doesn't belong on templates, but in the [component.build] section, so that if Alice creates an application from a template, commits it, and then Bob checks it out, Bob can still get the prerequisites info, even though Bob never sees or uses the original template.

It doesn't matter much at the tyre-kicking phase, I guess. And of course we could run checks/print prereqs/etc. on instantiation as well. Just thinking of the post-instantiation lifecycle.

[itowlson]

I had a look at scanning the build output to detect tool setup issues (as opposed to code that just doesn't build), and it kinda works, but I can't see an easy way to have the build output stream to the terminal and capture it to examine the failure. We could do it using a lower-level API, but I bet that would still end up compromised because of things like terminal-based output colouration. Sigh.