Launch VSCode via PYTHONBREAKPOINT and Python 3.7's breakpoint() function.

[mingwandroid]

Copied from: microsoft/vscode#60853

In my workflow I am used to inserting import pdb; pdb.set_trace() to break into a fairly minimal CLI debugger. How awesome would it be instead if I could launch into VSCode with as much debugging context available as possible?

I think it would be very nice indeed.

CC @zooba.

[lee-b-sk]

NOTE: this is important for codebases where each coder uses their own preferred editor, debugging tools, etc. Not just to avoid requiring use of VSCode, but to allow use of VSCode, where other editors / debuggers are normally used. It's a simple, but important standardised abstraction layer.

[fabioz]

Well, breakpoint() works for programmatic breakpoints (when it's already started with a debugger), but it doesn't start the debugger directly.

I think that for this to work the ideal scenario would be to have a way to have the client (VSCode) already listening for connections, that way, when breakpoint() is used, if the client is still not connected, it can automatically connect to that session and start the debug session (@int19h I remember there were plans to do that already, do you know the current state of this?).

The not-so-ideal scenario would be start to listen for connections once that's done and have the user do a manual attach -- but this is probably not that much better from having the user write input() and then use the attach to pid which is already implemented anyways... the upsides in this case is would be that it'd work for PyPy and CPython debug builds, where attach to pid is not available.

[int19h]

We have listen mode in the extension now, but it's not like PyDev or PyCharm, in that you have to explicitly start the server (F5), and it'll only handle one incoming connection before stopping. So it's not always-on.

On a higher level, though, this is more like the Windows thingy where when it sees a crash, and there are debuggers installed, it'll prompt you to attach one of them to the process. I would expect this to behave very similarly - basically a magic incantation to place into PYTHONBREAKPOINT that will 1) start the debug server inside the debuggee, 2) spawn VSCode and tell it to connect to that server, and 3) wait for it to connect.

In fact, on Windows, we might even be able to tap into the existing debugger dialog for this, for VS.

[niderhoff]

Well, breakpoint() works for programmatic breakpoints (when it's already started with a debugger), but it doesn't start the debugger directly.

Hello,

can you elaborate what you mean by that, please? I think I might not understand. As far as I understand PEP553 it does in fact import and start a debugger (pdb by default).

[fabioz]

Well, breakpoint() works for programmatic breakpoints (when it's already started with a debugger), but it doesn't start the debugger directly.

Hello,

can you elaborate what you mean by that, please? I think I might not understand. As far as I understand PEP553 it does in fact import and start a debugger (pdb by default).

I mean that internally when you're running with debugpy it customizes things so that breakpoint() makes a programmatic breakpoint (so, the program would pause at that point using debugpy instead of pdb).

[brechtm]

My particular use case for this is to speed up debugging. When debugging a Python application in VSCode (or other IDE's), it runs much slower compared to running the application regularly because of tracing. This means it can take a much longer time to reach the point in the program's execution where one would want to pause it to inspect the state in the debugger.

It is possible to to eliminate this speed penalty by adding a breakpoint() (import pdb; pdb.set_trace() in Python <3.7) line in the source code and run the application directly with Python from the command line. This will run the application at full speed, but drop into PDB upon reaching the breakpoint. This works well, except that the PDB command line is a much more clumsy environment to debug code. Hence, I want to drop into the VSCode debugger when reaching the breakpoint() line.

This is how this can be achieved:

• install debugpy in your project's virtual environment
• create a file vsattach.py in your project root:

  def debugpy():
      import debugpy
  
      port = 5678
      debugpy.listen(port)
      print(f"Attach the VSCode Python Debugger to port {port}")
      debugpy.wait_for_client()
      debugpy.breakpoint()

• create the Python Debugger: Remote Attach launch configuration
  • from the Add Configuration button when launch.json is opened (accept the default options)

        {
            "name": "Python Debugger: Remote Attach",
            "type": "debugpy",
            "request": "attach",
            "connect": {
                "host": "localhost",
                "port": 5678
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "."
                }
            ]
        },

• in your terminal (in VSCode or elsewhere)
  • set the PYTHONBREAKPOINT environment variable
    export PYTHONBREAKPOINT="vsattach.debugpy" (for bash)
  • run your python application from the command line
    • when the breakpoint is reached, the application will print "Attach with VSCode debugby to port 5678"
    • now run the Python Debugger: Remote Attach launch configuration