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