Revise Go language support section#311
Conversation
Added more details where necessary. Factored code examples out into separate files and included them. Made the "Testing the add component" section consistent with other examples involving the example host.
vados-cosmonic
left a comment
vados-cosmonic
left a comment
There was a problem hiding this comment.
LGTM 🚀
Just a few nits, and this should be ready to go!
Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
|
|
||
| Running the `wkg wit fetch` command will resolve the imports and populate your `wit` folder with all relevant | ||
| imported namespaces and packages. | ||
| Running the `wkg wit build` command encodes the WIT into the Component Model binary format. |
There was a problem hiding this comment.
The title of this section says it's about "resolve and download imports" so as a reader I have questions about why I am doing this encoding malarkey. After all, "resolve and download" is what fetch does, so why am I not doing that?
Looking ahead to section 3, I am guessing it is something like: in order to use go tool wit-bindgen-go, we must have a package (that is addressable using package notation) rather than a WIT text tree: therefore we must do a wit build rather than a wit fetch.
Is that correct? That go tool wit-bindgen-go can't operate on the text tree, only on a binary package reference? I'm a bit surprised by that but the one thing I do know about Go is its infinite capacity to surprise me! grin
If that is the reason, I'd suggest explicitly explaining this context, because reading this now the build step feels a bit arbitrary, likely as a result of partial updates as the Go tooling has changed over time...
3 participants
Added more details where necessary. Factored code examples out into separate files and included them.
Made the "Testing the add component" section consistent with other examples involving the example host.