You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Launch VSCode via PYTHONBREAKPOINT and Python 3.7's breakpoint() function. #216
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?
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.
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 (Pavel Minaev (@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.
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.
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).
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).
Activity
lee-b-sk commentedon Jan 15, 2020
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 commentedon May 6, 2020
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 (Pavel Minaev (@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 commentedon May 6, 2020
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
PYTHONBREAKPOINTthat 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 commentedon Jan 23, 2022
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 commentedon Apr 29, 2022
I mean that internally when you're running with
debugpyit customizes things so thatbreakpoint()makes a programmatic breakpoint (so, the program would pause at that point usingdebugpyinstead ofpdb).