You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As i played around with that concept more, I thought what would be really cool is to have something like spin buildx, which reads the toolchain requirement for a specific spin app (in a .toolchains file), spins up a container with the required toolchain, run spin build and export the build artifacts back to host system.
I did a small poc of that and it seems to have worked for simple cases I tried:
$ spin new -t http-rust http-rust-buildx --accept-defaults
$ cd http-rust-buildx
$ cat >> .toolchains<< EOF
rust=1.82.0
spin=3.1.0
EOF
$ ls ./target/wasm32-wasi/release/deps/http_rust_buildx.wasm
ls: ./target/wasm32-wasi/release/deps/http_rust_buildx.wasm: No such file or directory
$ ../spin-terminal/buildx
✔ connect 0.2s
✔ loading module 0.7s
✔ parsing command line arguments 11.2s
✔ wasi: Wasi! 0.7s
✔ Wasi.build(
source: ✔ ModuleSource.resolveDirectoryFromCaller(path: "."): Directory! 0.0s
): Directory! 1m24.0s
✔ Directory.export(path: "."): String! 2.4s
Full trace at https://dagger.cloud/rajatjindal/traces/4378964d0128b39a071bdd0bb8fe4993
/Users/rajatjindal/go/src/github.com/rajatjindal/http-rust-buildx
closed the terminal succcessfully
$ ls ./target/wasm32-wasi/release/deps/http_rust_buildx.wasm
./target/wasm32-wasi/release/deps/http_rust_buildx.wasm
if we include this toolchains file in examples/templates (or as a spin.toml entry as suggested by @itowlson), then using this plugin will significantly reduce friction for new users. e.g. while for rust, the toolchain requirement is simple, but for golang, we need golang, tinygo and wasm-tools and then installing specific versions of that, all that can be simplified.
Please let me know your thoughts.
The text was updated successfully, but these errors were encountered:
I'd be keen to see this, although I'm not sure how I feel about including support for particular plugins in templates. That feels like a discussion we should have, though, as a broader thing: it's not invasive, and it would save users of relevant plugins having to copy incantations themselves. (And give the plugins themselves an It Just Works quality!)
I wrote a plugin
spin terminal
(https://github.com/rajatjindal/spin-plugin-terminal) based on dagger, which provides a container shell with the required toolchains.As i played around with that concept more, I thought what would be really cool is to have something like
spin buildx
, which reads the toolchain requirement for a specific spin app (in a.toolchains
file), spins up a container with the required toolchain, runspin build
and export the build artifacts back to host system.I did a small poc of that and it seems to have worked for simple cases I tried:
if we include this toolchains file in examples/templates (or as a spin.toml entry as suggested by @itowlson), then using this plugin will significantly reduce friction for new users. e.g. while for
rust
, the toolchain requirement is simple, but forgolang
, we needgolang
,tinygo
andwasm-tools
and then installing specific versions of that, all that can be simplified.Please let me know your thoughts.
The text was updated successfully, but these errors were encountered: