Running wanix+wasi in the command line

[ajanicij]

Hi! I have just "discovered" wanix, and I think it's awesome!
I have been thinking about something similar for a while, but you guys beat me to it. Here's my motivation: I would like to have a tool to run WASM code in the command line, and instead of WASI, run it in a namespace in Plan 9 style. So, marrying wanix with a WASM engine in Go. Would it be possible - no, scratch that, I know it would be possible, what I would really like to know is how do I get there? I know of pure Go WASM engines, like wasmer-go, so I would like to combine that with wanix namespaces.

[progrium]

Yes! Glad people are seeing this possibility as well. The work is somewhat started as this is a use case I'm excited for as well. There are a couple ways to approach this and I don't see why we can't support them all since they are related, but it would help to get feedback on what to prioritize.

wanix console

First, I have planned what I currently think of as wanix console. Most immediately, this toolchain subcommand would give you an interactive shell by running a local version of wanix.run in a hidden webview. Behind the scenes it would be on a domain like default.console.local. We can also have named consoles (wanix console foobar -> foobar.console.local).

You could imagine a detached mode (wanix console -d foobar) that doesn't attach an interactive terminal, just serves foobar.console.local for you to access via browser if you wish. One dynamic here is that because we can cache the whole site to be used offline, once you browse to foobar.console.local, you can terminate wanix console and you'd still be able to use foobar.console.local assuming it's not using any services from wanix console. Mainly I'm think about the network proxy which is somewhat in place.

Want a console to be some customized environment or immediately run a command? You can use /web/opfs/etc/profile (works today, possibly not final location) to specify a shell script to start a custom environment or specific task. Later we could facilitate this at the CLI level if it makes sense.

wanix mount

Another path is what I started as wanix mount. This was started before wanix serve and it probably doesn't work at the moment, but the idea is that it would use FUSE (and later more platform specific mechanisms) to mount a Wanix namespace on your actual filesystem. When I started this I had in mind a non-web version of Wanix with no hidden webview and no /web, focusing on /task and /cap. This is where a Go WASM runtime could be used to register as a task type. Maybe optionally, native processes as well.

combined

Obviously, these two commands could be combined to one command or be two commands but as different workflow entrypoints. The wanix console command could have a flag for whether or not it uses a webview and includes /web, or behaves as wanix mount is described where instead it has a native wasm task type and/or native process task type. One complication here is that the builtin shell environment depends on v86, which currently only works in the browser. However, there is no reason a pure wasm shell couldn't be used instead, but it just requires working out the conceptual model for all this.

Similarly, wanix mount could mount console environments. So wanix mount foobar /mnt/foobar (or whatever) would run foobar.console.local in a hidden webview, and mount the root namespace on the host as /mnt/foobar. This makes sense because otherwise, as originally described, there is no way to specify what that root namespace is that's mounted. I believe the current wip hardcodes something. Obviously, wanix console could have a mount flag as well.

Perhaps the future is just wanix console... since wanix serve uses localhost+port, but ideally environments should have their own domain. Since otherwise there could be conflicting data.

---

So that's what's been in my mind. Open to feedback on all this, or alternative ideas. Unless y'all have a specific use case to chime in with, I'll probably initially focus on interactive wanix console with web in hidden webview because that's the easiest thing. Let me know if that would be good enough for now, otherwise I can prioritize the interface for new task types and an embedded wasm engine after that.

Keep in mind, in all these cases, the wanix environment is totally isolated from the host system unless you use pickerfs to mount a directory inside. Way back, I had imagined a scenario where enough of the host filesystem is mounted inside that you could use wanix to run a shell for working with the host system, where it could be possible to use it as your system default shell. That is much more ambitious and will have to wait.

Anyway, thanks for starting a discussion on this and would love feedback from anybody else as well.

[ajanicij]

That is all good, but the use case I had in mind was more in the lines of how Deno does it for TypeScript/JavaScript modules: as a browser for code. That would require running WebAssembly locally, with a runtime.
This would mean the user runs some utility from the command line that runs code just like how Deno runs TS or how Python interpreter runs Python scripts, but 1) securely, because that code gets a namespace and 2) this is WebAssembly, so the user can have anything that was compiled to WebAssembly bitcode. That bitcode doesn't even have to be fetched from the local file system - that is why this utility would be a browser for code.

[progrium]

I see. Basically run a WASI task directly from CLI using a file or URL. Similar to how Deno makes you specify capabilities via flags, we'd have to let you define the namespace... somehow.

Maybe flags/args would work with bind notation similar to Docker mounts (wanix run -b "#task:/task" -b "#cap:/cap" URL). Maybe shorthand for built-in system file services (wanix run -b task -b cap URL) making it pretty similar to Deno. More complex namespace definition would have to be done via a script... or maybe providing a predefined environment domain (using foobar.console.local would be wanix run -c foobar URL).

Something like that. I think I'd want to let some other things shake out first, but seems reasonable.

[joeblew999]

interesting discussion . Wanix is like a technology ahead of its time with a myriad of potential.

I use this setup to do a similar thing without wanix , but was thinking about using them together also.

First you have wazero to run the WASM.

then you need a plan9 FS . There is a golang implementation of plan9 plumber out there too that uses nats Jetstream.

Plumber is a user level file system .

https://9fans.github.io/plan9port/man/man4/plumber.html