Notification Bot (Mar 26 2025 at 00:17): Notification Bot (Mar 26 2025 at 00:17):matt rice has marked this topic as resolved.
matt rice (Mar 26 2025 at 13:31):Well, the project would like to avoid the additional cargo install phase above and beyond installing wasmtime. I don't suppose you guys would want anything like this added to wasmtime either as a separate cli wasmtime-workspace-runner or subcommand of wasmtime wasmtime workspace run?
Alex Crichton (Mar 26 2025 at 15:01):Personally for something like this I've wanted something like -S inherit-all which inherits all WASI things into the wasm component/module rather than the default inherit-nothing. That I think would make it possible to build such an integration as this outside of Wasmtime itself.
Otherwise I'd personally be hesitant to add something so integration-specialized to the CLI itself
matt rice (Mar 26 2025 at 15:05):I'm pretty new to using wasmtime, so I'll try to read and figure out what -S does, so I can understand what you mean :)
However I find your hesitation reasonable, I find it all a bit icky myself.
Alex Crichton (Mar 26 2025 at 15:06):Sorry this is a casual though I have about possible future functionality in Wasmtime, you can probably mostly discard it
matt rice (Mar 26 2025 at 15:11):My thought was mostly that if I could get runner = "cargo run -p foo_runner" working and not clashing with env vars, I could just provide it in the workspace and avoid the cargo install phase entirely then I don't think we'd have any problems just using this hack.
matt rice (Mar 26 2025 at 15:34):The only thing I can think to move to make it less cargo specific is say, some way to specify a config file for dirs/env vars instead of just command line args then my runner command could just point to that... I'd likely still need to cargo metadata to get the path to the workspace_root. That at least seems like it is getting less toolchain specialized.
Last updated: Apr 10 2025 at 00:13 UTC