Replies: 4 comments
-
|
A few things first. The connection can be set up to go in either direction - that's why we have both "connect" and "listen". Also, if you are using Furthermore, when you use "connect", the debuggee doesn't spawn the adapter process (which I think is what you mean by "server"?) - it just connects to whatever port you give to it and starts talking DAP. Normally, that thing it connects to is the adapter process, but you're in charge of spawning it now, and you can spawn it on another machine etc. There's nothing requiring that process to be on the same machine as the debuggee, and, indeed, in VSCode remote scenarios with "connect", it usually isn't. As far as port numbers go, there's no default port in debugpy; you always have to explicitly specify it. We've been using port 5678 in the documentation examples for over 10 years now, but it really is meant to be just that - an example. Lastly, you can prevent debugpy from spawning an adapter process even in "listen" scenarios with a recently added and yet-undocumented feature: |
Beta Was this translation helpful? Give feedback.
-
|
As for the rationale, there are a number of reasons for this arrangement, but the biggest one is process lifetime management, especially in multiprocess debugging scenarios. The problem with any debugger that runs fully in-proc is that if the process crashes or even just locks up (e.g. something is hogging the GIL), so does that debugger. Reliably killing child processes when debug session for the parent terminates can also be difficult. We actually tried to implement multiproc in-proc at first in ptvsd 4.x, and the problems that resulted were the primary motivation for the current architecture. There are some other benefits, too - in particular, an outside process that controls spawning the debuggee can capture stdout/stderr much more reliably than anything that's running in-proc. Coincidentally, this is why you might see some output getting captured in "launch" mode but not in "attach" (the latter necessarily has to do everything in-process). |
Beta Was this translation helpful? Give feedback.
-
|
Lastly, as far as supporting "pydev compatible debugging servers", this is not a goal for this project. Our goal is to provide a debug adapter that supports DAP-compatible clients / IDEs. Unfortunately, there's a lack of standardization on how a DAP client would expect to connect to an adapter beyond stdio, but the informal expectation is that it should be possible for one side to set up a port for the other side to connect to. As noted above, we support this scenario in both directions, so if you mean an IDE that opens a socket for a DAP adapter to connect, it should work with |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much! I did not find this documented, all documentation only
talks about the server method.
Which is pretty handy for some scenarios I have to admit, but it can be
annoying if you rather want the breakpoint to connect to you, wherever it
may come from.
Thank you very much for your kind explanations!
I will look into this :)
…On Wed, Jan 18, 2023 at 8:52 PM Pavel Minaev ***@***.***> wrote:
Lastly, as far as supporting "pydev compatible debugging servers", this is
not a goal for this project. Our goal is to provide a debug adapter that
supports *DAP-compatible* clients (IDEs). Unfortunately, there's a lack
of standardization on how a DAP client would expect to connect to an
adapter beyond stdio, but the informal expectation is that it should be
possible for one side to set up a port for the other side to connect to. As
noted above, we support this scenario in both directions, so if you mean an
IDE that opens a socket for a DAP adapter to connect, it *should* work
with debugpy.connect() - and if it doesn't for some particular IDE that
you're using, please file a bug!
—
Reply to this email directly, view it on GitHub
<#1177 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEQBMDDJOGZB4DKHEQVWSDWTBCXNANCNFSM6AAAAAAT7DCD44>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I think I just really need to understand the rationale why debugpy went the way to run the server in the executed code, can someone explain, or link explanations to this choice?
I have been struggling with this for a while now, and find debugpy is really the worst solution in this regard, as you have to client side manage port collisions, if you run multiple projects or multiple iterations of the same project at the same time, and it is a nightmare in providing support for multiple developer environments.
I just really want to understand, why this was chosen, especially since pydevd, which it basicly is built upon, uses the way more traditional approach to use a client in the debugged code, and connect to a debugging server.
And while this might be handy in some situations, most of the time I just wish, you would not have gone all-in, and only made it bidirectional, so the client side server is an option, not the the only choice, which basicly also disallows to use debugpy with pydev compatible debugging servers. Maybe I have overlooked this option, but if this is possible, I would really appreciate a mention of it.
(I want to especially note how annoying it is that you use the same port as the pydev debugger uses for the debugging server for the client debugger by default)
Beta Was this translation helpful? Give feedback.
All reactions