There is

In python:

import debugpy
debugpy.listen(5678) # debugpy will open 5678

Then add the following configuration to dape

(add-to-list 'dape-configs
`(debugpy-attach
  modes ()
  host "localhost"
  port ,(lambda () (read-number "Port: "))
  :type "debugpy"
  :request "attach"))

Supposedly there is a way to attach by pid with python3 -m debugpy --listen localhost:5678 --pid 12345, but that failed, both on osx and linux.

Expect to debug the dape debugger

Did you use the debugpy adapter with the following configuration from the readme? (add-to-list 'dape-configs `(debugpy modes (python-ts-mode python-mode) command “python3” command-args (“-m” “debugpy.adapter”) :type “executable” :request “launch” :cwd dape-cwd-fn :program dape-find-file-buffer-default))

I have tested this quite often at my day job so I am a bit surprised you bumped into issues. But thats not to say that Dape will contain warts until there is enough feedback and testing. It would be great if you could dump the contents of the dape-debug buffer into an issue on github!

DAP has some issues as well, extremely loose specification, the overwhelming majority is tested with vscode and a lot of cruff is hidden inside in the plugins for vscode. I was close to putting it in the bin at several points.

Other problems I’ve encountered is a weird way that it stores configuration options once you’ve told dape to connect to stuff. The UX around that needs work before it’s plug-and-play.

Usability feedback is appreciated, the dape command tries to do a lot of stuff, maybe to much.

It models the way one would use a command line tool. For example if we run dape debugpy it executes the configuration above with all of the plist entries as the default command line arguments. If we want to overwrite any “argument” or add an “argument”, lets say we wanted to run the python file with some enviroment variable then call dape with debugpy :env (:ENV “MY_ENV”).

The other part is actually evaluating all of the symbols and functions in the config and adds the result into history for ease of access.

Being able to see all the relevant variables, a la the GDB multi-window support in Emacs, is also nice. Which makes me wonder why we can’t just reuse that, as there’s surely man-years of work to make that stable and effective.

I am regretting not looking into this when I started, even though I kinda like having one “big” buffer with all of the information, using the tried and true GUD interface would meld better with one of the goals of package of being closer to emacs. So I am looking into the possibilities.

Still, an impressive effort, and I’m surprised how little code dape actually is. I’m sure it’ll improve quickly once people start giving feedback.

Thank you, it would not have been possible for me to get this far without Wireshark. A little reverse engineering is always fun :) And thanks for your feedback!

Author here, if you have any suggestions or bump into any issues please open a ticket. I have some extra free time on my hands a couple of months going forward.