support dlv-dap install in upstream (delve/service/dap)

[georgettica]

1. What version of Delve are you using (dlv version)?

Delve Debugger
Version: 1.8.0
Build: $Id: 6a6c9c332d5354ddf1f8a2da3cc477bd18d2be53 $

2. What version of Go are you using? (go version)?

go version go1.17.5 darwin/amd64

3. What operating system and processor architecture are you using?
   macos, amd
4. What did you do?
   I installed dlv-dap using vscode and wanted to update it
5. What did you expect to see?
   I expected the dlv-dap to have a release in delve and an explanation on how to install it
6. What did you see instead?
   I saw in the vscode install it installs v1.8.0 via the commit number and saved it in a different file.

updating it (using ugbt install dlv-dap v1.8.0 updated the dlv binary instead
ugbt == https://github.com/kortschak/ugbt

[georgettica]

@kortschak as the maintainer of ugbt

[kortschak]

I don't use delve, but from what I can see this is working correctly, the DAP server is part of the dlv executable, so upgrading the dlv binary does upgrade dlv dap. I'm not sure how ugbt install dlv-dap v1.8.0 would even work since AFAICS (from a brief dive into the delve code) that dlv doesn't use busybox style sub-command resolution and doesn't install a dkv-dap command into $PATH (both confirmed by experiment), so the correct way to use ugbt here would be ugbt install dlv v1.8.0. As a note, ugbt will not correctly handle busybox style sub-command resolution (this could be made to work, but probably won't be). Edit: This works already if the subcommand is a symlink to the allcommand (experimentally determined).

[georgettica]

If this is the case, is it possible to opt-out of busybox style sub-commandss in the tool?

Not for this repos immediate action but still with asking

But regarding here, is it worth to migrate the code into something that is compliant with ugbt? And if so how?

[kortschak]

I just installed dlv using make and it doesn't install a busybox-style sub-command system and I just tried to construct one in the normal fashion and dlv is unaware of it (as expected from the code). AFAICS&FWIW, this all works correctly from an ugbt perspective.

[polinasok]

The way to update dlv-dap from vscode is to use Go: Install/Update Tools from Command Pallete. In the past dlv was fixed at the most recent stable version (often quite stale) and dlv-dap was regularly refreshed at master to keep up with rapid development. Recently dlv release schedules switched to monthly while dlv-dap development slowed down, so we are on our way to merge the two binaries again. In the meantime, we had a breakage at master, so dlv-dap was pinned to a fixed version to keep it more stable, which is unfortunately now lagging behind the newly released dlv v1.8.0. That's on us, and we will get right on it. @hyangah @suzmue

In the meantime, dlv and dlv-dap are really the same full dlv binaries with all the same subcommands, just not always at the same version. If you invoke your server externally and connect to it via a port, you can use either of them. If you want vscode to use the right version of dlv-dap, you can manually overwrite that binary yourself. For example:

$ which dlv
/path/to/dlv
$ which dlv-dap # or see what path is printed by Go: Install/Update Tools
/path/to/dlv-dap
$ cp /path/to/dlv /path/to/dlv-dap

[kortschak]

If /path/to/dlv-dap is made to be a symlink to /path/to/dlv, these updates will Just Work™.

[hyangah]

As mentioned in golang/vscode-go#1977, dlv-dap binary will be no longer necessary in the vscode go next release.