Allow ptvsd to run as server and let code connect to it

[theoribeiro]

For some use cases like when debugging server applications with auto-reload or microservices running in tandem it is desirable to run the debugger as a server and let the code connect to it, pretty much like what PyCharm does with pydevd. This allows the user to connect to the debugger every time the code runs without having to attach the debugger to a remote process.

It also allows for remote instances (or docker containers) to connect to a developer's machine without having to open ports on the former since the connection is only outbound from the instance perspective.

Is this something that is being considered or that there are any technical limitations to implement?

[int19h]

ptvsd itself has been able to do it for a while now - there's an undocumented function ptvsd.attach() that's a counterpart to the usual ptvsd.enable_attach(), with the only difference being the direction of the connection. In our recent redesign of the debug adapter, it also gained some missing pieces to support this scenario.

However, this was meant more for fully programmatic scenarios, where the DAP client is not an IDE - there's no support for this on the VSCode side of things. It would be technically feasible to implement an "attach" debug configuration mode that, instead of trying to connect, would wait for an incoming connection - indeed, we have almost all bits for that in place, it's just not something that's officially supported (and neither is ptvsd.attach()).

But UX-wise, this would still require you to press F5 to start the listener on the IDE side, and that listener would only be able to handle one incoming connection from the debuggee; once the debuggee disconnects, VSCode considers the debug session to be over, and shuts down the adapter as well. Which sounds like it doesn't cover the scenario that you are envisioning.

Can you tell more about that scenario, and how having this connection mode would improve it?

[theoribeiro]

Sure, let me try to get into more detail. Please let me know if you need any more. I'll start with the most compelling use case since it is an actual need and not just for convenience. We're trying to switch to VSCode from PyCharm for the flexibility it offers but can't while we can't debug our lambdas when deployed.

Scenario 1 - Serverless Applications

When developing serverless apps you don't have control over the server the function is running. You don't know the IP address and you surely can't open ports to connect to. This reverse connection allows for the developer to open a port on her machine and let the Lambdas connect to it, allowing debugging on that environment. All you need to do is deploy the code and pass the IP address, port and a "debug" flag as environment variables to your lambdas.

Scenario 2 - Serverless Applications Ran Locally

Most of the tooling for Serverless development needs this to work properly as well if you want to be able to debug. The Serverless Framework toolset is written in Node.js and uses a Python script to invoke the Lambdas when running sls offline with the serverless-offline-python plugin installed. It starts a API Gateway that routes requests to your functions. This means that you can't "launch" Serverless with a Python debugger (because it's Node.js), you need to start a remote debugging session. By having the script that invoke your Python code connect to the IDE debugging server, you only need to hit F5 to start listening once and then every time your Frontend hits the local endpoints, Serverless would connect to the IDE.

Scenario 3 - Microservices with Docker containers

Whether you're using Minikube or just plain docker-compose to develop and test your microservices locally, you need to remotely connect to your services to debug. If you have multiple microservices, if you can make them connect to your IDE, instead of having to open a different port in each of your docker services is again a lot more convenient.

---

All of the use cases above are based on a passive service that is waiting for connections from a frontend client. Since you don't know when the frontend will hit the microservice, you often want to have a debug server listening for when it happens, instead of having to synchronize your IDE by pressing F5 after call the API with curl or the frontend.

Even after the client code disconnects, the IDE could restart the debug server, like what PyCharm currently does.

[xavArtley]

Eclipse and pydev works like pycharm for the debug server. And it's the only feature wich make me stop from switching to VScode
Here is an exemple of the use :
https://discourse.bokeh.org/t/debugging-bokeh-serve-application-using-pycharm/1549/7?u=xavier_artusi