Add "restart" option to launch.json (“listen” mode)

[martijnthe]

It would be nice if the python / debugpy launch.json type would also support a "restart" option, like the nodejs one does.

In particular, when using the listen/server mode, it's nice to have server be restarted automatically after the client has disconnected. Otherwise, one has to restart it manually every time.

[int19h]

There's #577, but note that it's specifically about re-attaching. The debugger is not in charge of restarting the process - indeed, in case of attach, it generally can't be since it doesn't observe the process launch and so it doesn't know the command line necessary to restart.

[martijnthe]

@int19h thanks for your reply.

Yes, that sounds similar but is indeed about the “attach” scenario for which having a “restart” option is trickier because of the reasons mentioned.

FWIW, Pycharm’s “Remote Debugging” feature also implements this. There, the IDE plugin (pydevd) is always in server / “listen” mode and the code being debugged is always the client / initiating the network connection.
Pycharm doesn’t have an explicit “restart” option. It just automatically starts/continues accepting the next client when the previous one disconnects.
Debugpy (in “listen” mode) on the other hand, exits when the the client closes the connection and one then needs to restart the launch.json task again…

[int19h]

So to clarify, you don't expect the debugger itself to be in charge of restarting the debuggee, but you want a more convenient arrangement to allow the self-restarting server to also auto-attach? And making the IDE remain in "listen" mode after the first client disconnects would fix that? Because I think the latter could be done with "restart" in a much simpler way than #577 requires.

[martijnthe]

So to clarify, you don't expect the debugger itself to be in charge of restarting the debuggee,

Correct. The debugger/IDE doesn't know how to do that. (In my use case, I will do that "manually" by making a request to a .py web server that will then attempt connect to the IDE/debugpy server.)

but you want a more convenient arrangement to allow the self-restarting server to also auto-attach?

I'm not sure if I follow the "auto-attach" part here.
I'd like for debugpy in server ("listen") mode to self-restart and accept connections from a debuggee again.

Right now the behavior seem to be: listen, accept connection from first debuggee, then when that debuggee (debugpy client) terminates, the debugpy server is stopped (and I need to re-run the vscode launch task).

And making the IDE remain in "listen" mode after the first client disconnects would fix that?

Right. I would not need to restart the vscode launch task then every time the debuggee terminates (which in my use case happens once the webserver request that is being debugged has completed).

Because I think the latter could be done with "restart" in a much simpler way than #577 requires.

Yup, agree! I think in the reverse ("attach") mode this is a bit tougher, because the debugger/launch task would need to know how to restart the debuggee?

For completeness (but I guess this is clear by now), this is my launch.json task definition:

        {
            "name": "Start debugpy server",
            "type": "python",
            "request": "attach",
            "listen": {
                "port": 8888,
                "host": "0.0.0.0"
            }
        },

[int19h]

To clarify the terminology I use wrt debugpy, "attach" refers both "listen" and "connect" scenarios, "debug server" refers to the part of debugpy that runs inside the debuggee, and the part that's listening on the socket when you use "listen" is the "debug adapter". That is, "debug server" does not necessarily imply that it listens, only that it services requests once connection is established in whatever direction.

That said, "allow the self-restarting server to also auto-attach" referred to the webserver, or rather the process that hosts it. I was imagining a setup similar to hot reload in Django or Flask, with a parent watchdog process that kills/restarts the actual webserver-debuggee process as needed. If the adapter supports restart when running in "listen" mode, the debuggee can do debugpy.connect() (or the watchdog can do the CLI equivalent when it spawns the webserver), and things should just work.

[int19h]

#1217 is the tracking item for this work - closing this one to reduce confusion.