No description
Find a file
2023-06-29 20:27:27 +02:00
.buildr chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
api initial working version of plugin SDK 2023-05-24 22:11:05 +02:00
examples/hello_world_go chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
mem chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
protocol/generated/rpc/v1 initial working version of plugin SDK 2023-05-24 22:11:05 +02:00
.gitignore chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
api.go chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
buf.gen.yaml fix: module path 2023-05-18 18:21:44 +02:00
buf.work.yaml feat: initial draft of SDK 2023-05-08 15:21:31 +02:00
buf.yaml feat: initial draft of SDK 2023-05-08 15:21:31 +02:00
context.go initial working version of plugin SDK 2023-05-24 22:11:05 +02:00
entrypoint.go chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
executor.go initial working version of plugin SDK 2023-05-24 22:11:05 +02:00
go.mod chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
go.sum chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
imports_stub.go feat: initial draft of SDK 2023-05-08 15:21:31 +02:00
imports_wasi.go chore: prepare Go 1.21/Tinygo 0.28 2023-06-29 20:27:27 +02:00
LICENSE Initial commit 2023-05-04 15:06:21 +00:00
logger.go fix: module path 2023-05-18 18:21:44 +02:00
README.md fix: module path 2023-05-18 18:21:44 +02:00
registry.go feat: provide plugin inventory 2023-05-13 17:46:09 +02:00
state_proxy.go initial working version of plugin SDK 2023-05-24 22:11:05 +02:00

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:

  1. Create a new Go module
  2. Reference this SDK (go get -u code.icb4dc0.de/buildr/wasi-module-sdk-go)
  3. create a main.go with an empty main() function
  4. implement the sdk.Module interface for your module
  5. implement an init() function that registers your module and the SDK's type registry
  6. 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.