Create debug adapter in Python

[DonJayamanne]

Currently the debug adapter is written in typescript, and in the launch handler we start the python process that's running PTVSD, after this we connect the VSC streams to the python process streams.
From then on the Typescript DA doesn't play any role.

VS Code have some changes in the pipeline that'll make it possible to write the debug adapter in Python. I.e. just before the debug is launched we have the ability to provide the path to the selected (workspace) python interpreter, along with any custom arguments.
https://github.com/Microsoft/vscode/blob/master/src/vs/vscode.proposed.d.ts#L384

However this seems to be in preview (no idea when they'll release this).

Either way, what's good about this is the fact that we can build the debug adapter completely in python (as part of PTVSD).

@brettcannon @ericsnowcurrently @karthiknadig @int19h cc

[DonJayamanne]

@karthiknadig would it be possible to write the DA in python for VS? Please could you check with the VS DA team.

[int19h]

VS implementation doesn't have a debug adapter in that sense - they provide us with an extensibility point for stuff like launch and attach, that works via .NET interfaces, which are implemented by code in the same process as VS itself. Turning it into an out-of-proc Python implementation would be a substantial change, and I'm not sure it's even feasible for all the VS features that we need.

[ericsnowcurrently]

I'm definitely on board with writing the adapter in Python. TBH, I still think that ptvsd should be a fully compatible implementation of the protocol. Then we could use it directly in VSC, with no need for a second adapter. For VS (or any other non-protocol needs), we'd have shims on top as necessary.

Of course, taking this approach is not practical in the short term, so having a shim to use in VSC would be fine for now. Keeping it in the ptvsd repo makes sense since it's not specific to our extension (or is it?).

[ericsnowcurrently]

@int19h As to an out-of-proc Python implementation, I'd like to understand better about:

• what the "adapter" for VS would look like (what it looks like now in C#?)
• what the different challenges are to using a Python implementation in-proc would be
• what's this restriction about out-of-proc execution (i.e. subprocesses)

Are there quick answers (or perhaps it would be better to talk about it in the debugger meeting)?

[int19h]

Take a look at the code here, ignoring the "Debugger" subfolder.

https://github.com/Microsoft/PTVS/tree/master/Python/Product/Debugger

[int19h]

I don't see how we can avoid a second adapter in VSC though. By its very nature, ptvsd has to run in the debuggee process. For remote scenarios, this means that it's talking to something over a socket; and VSC cannot talk debugger protocol over a socket (remotely and in a supported way). And for local scenarios, it can't talk over stdin/out, because the user code will be using it for its own purposes - so, again, we need a socket.

[karthiknadig]

If we move the socket connection from VSC-ptvsd to ptvsd-pydevd. Then we can have a out-of-proc python only adapter. I see it like the broker-RAU-RHost that we have in RTVS.

[int19h]

That was a deliberate design choice by me and Steve back when this was all on the drawing board - that the protocol that goes over the wire is VSC DAP, and not pydevd protocol. Mostly because DAP is much cleaner, especially when it comes to security and potential attack surface (proven parsers instead of ad-hoc etc). But also because it is fully spec'd, and more likely to get adopted by other tooling.

Ideally, long term, the perfect solution is for VS and VSC providing the ability to talk DAP over a socket, with some standard way to set it all up transparently for the user, and including remote - then we wouldn't need the shims at all.