WSL Container API vs making a wslc.exe wrapper

[Peter Hultqvist (hultqvist)]

I'm wondering what the end goal is for the WSL Container API.

The WSL Container API is missing many features that the wslc.exe command already has.
The only feature I can see in the API not available in wslc.exe is the session creation.

I've found myself spending more time figuring out what's missing or behaving differently in the API rather than just calling wslc.exe directly.

Should we expect the API to eventually have all features available via wslc.exe?

Then, what benefit can we look forward to using the API vs a wrapper calling wslc.exe?
One benefit would be the strongly typed arguments, where an wslc.exe wrapper could have vulnerabilities in generating the command line arguments.

[Mark Adamson (mungojam)]

Our blocker using the API is slightly different. We use docker/containers as part of an internal shared nuget library that supports both windows (for local dev) and linux (for CI/CD).

The nuget package adds a hard requirement for a specific windows SDK which then has to be exposed in the package and then makes adding linux support tricky even when linux doesn't end up calling the API itself (it uses docker directly instead).

So we're resorting to using the cli for now which means we can still target plain old net10.0

[LionTech (TykoDev)]

Peter Hultqvist (@hultqvist) I was a bit impatient and I wanted to feel the sweet pleasure of hitting delete on docker desktop so I threw this together quickly (limited love given... for now) https://github.com/TykoDev/wslc-gui (there is also an executable using the new fancy "deno compile")

[Dawn Magnet (DawnMagnet)]

Another data point for the wrapper side: I went the wslc.exe route for a Compose shim (https://github.com/DawnMagnet/wslc-compose-go) for similar reasons to Mark Adamson (@mungojam). The CLI already had build, healthcheck, GPU and network flags the API lacked, and a plain Go binary avoids any Windows SDK dependency.

On the argument-injection concern: building argv as a list (no shell string) and parsing wslc output defensively has been enough so far, but the output formats aren't a stable contract, which is the real downside.

A typed API at CLI parity would definitely be nicer long term.