SupportsTerminateRequest and SupportsRestartRequest seem to be needed to allow the terminate request and the restart request (c.f. https://microsoft.github.io/debug-adapter-protocol//specification.html )

I haven't added the functionality for Terminate and Restart yet. We're capable of them but the DAP adapter implementation isn't quite there yet.

I'm not sure how these options can be used by editors. Maybe these flags will be need to be moved to the launch config when this DAP plugin allows the editor to invoke the build through the launch request.

The intention is the debug adapter implementation would translate these to command line arguments. It might be worth putting them into the launch config though just to keep things consistent.

Here's an example: https://github.com/docker/nvim-dap-docker/blob/27f73dae22a4be31caaacc37ce4ba8566a1fbcc5/lua/dap-docker.lua#L19-L29

Thanks for the example.

The intention is the debug adapter implementation would translate these to command line arguments. It might be worth putting them into the launch config though just to keep things consistent.

Sure. launch.json support can be following up.

Will this be used for build flags as well? (e.g. the user can write the build flags to launch.json instead of to the global editor config file) If so, the Launch handler will somehow need to be able to trigger the build.

I haven't quite determined how that is. For neovim, the adapter is the one that reads the launch.json file and it can then invoke the tool with the correct arguments. My initial thought was to have the editor translate the JSON launch arguments to the appropriate CLI arguments. I have to see how the VSCode side works though to see what is better.

My initial thought was to have the editor translate the JSON launch arguments to the appropriate CLI arguments.

👍

I have to see how the VSCode side works though to see what is better.

IIUC, in all of nvim, VSCode(startDebugging API), and emacs (dap-mode), DAP plugin can receive launch.json contents from LaunchRequest.

I've changed the method for how this works and it now supports a combination. Any arguments provided on the command line will be used (to facilitate direct usage or arbitrary args from a plugin/extension) but certain JSON arguments can be used to override any command line arguments. Options that are considered very common will go into JSON properties while the "args" can be a catch-all for everything else.

So launch.json would end up looking like this:

{
    "type": "dockerfile",
    "request": "launch",
    "dockerfile": "Dockerfile",
    "contextPath": "${workspacePath}",
    "target": "mytarget",
    "args": "--build-arg FOO=1"
}

Did you encounter an exception without this change?

This was mostly to allow the dap build command to reuse build but not require the required argument. Another portion of the code will catch that this is missing later but it allows calling buildx dap build and letting the context path to be sent later by the launch arguments.

It doesn't impact the normal build command because cobra will never let the code get there.