.buildr | ||
examples/hello_world_go | ||
exec | ||
mem | ||
.editorconfig | ||
.gitignore | ||
api.go | ||
context.go | ||
entrypoint.go | ||
executor.go | ||
export.go | ||
go.mod | ||
go.sum | ||
help.go | ||
imports_stub.go | ||
imports_wasi.go | ||
json_state_encoder.go | ||
LICENSE | ||
logger.go | ||
README.md | ||
registry.go | ||
renovate.json | ||
state_proxy.go |
Module SDK for Go
This module provides glue code to implement a buildr WASI module easily and quickly. To implement a new buildr WASI module:
- Create a new Go module
- Reference this SDK (
go get -u code.icb4dc0.de/buildr/wasi-module-sdk-go
) - create a
main.go
with an emptymain()
function - implement the
sdk.Module
interface for your module - implement an
init()
function that registers your module and the SDK's type registry - compile the module e.g. with tinygo
See also the examples directory to get started.
Dependencies
easyjson
Right now the SDK depends on easyjson to unmarshal the modules state as defined in the HCL configuration.
The main reason for this is that the reflection support in TinyGo is limited and for instance encoding/json
heavily depends on reflection.
The SDK itself uses protobuf (vtprotobuf) to exchange data with the host without reflection but this is not generic enough to support every possibility of module configuration (e.g. map<string, string>
would require extra encoding/decoding steps, same for map<string, bytes
).
Therefore, the SDK requires you to generate easyjson
compatible unmarshal functions.
slog
buildr is using slog
for logging (as soon as Go 1.21 is released it will move to the final version) and also the SDK is using it to allow modules log messages.
When using the SDK there's nothing to be done except using the logger the is provided by the ExecutionContext
.
Alternatively it'd be possible to log to STDOUT
/STDERR
but keep in mind that logs written to these streams directly will be 'mixed' with the output of other processes.