debugpy/debugger_protocol
Karthik Nadig df9c8fd9e0
Adds debug console completion (#772)
* Add support for debug console completion

* Add test files

* Adding tests

* Add supportsCompletionsRequest to _requests

* Add test for bad request

* Fix sorting issue in test

* Address comments

* Remove unsupported test for completions

* Add required argument to completions request in tests

* Fix linter issues
2018-08-28 18:33:28 -07:00
..
arg Run most of the tests under Python 2. (#405) 2018-05-02 18:05:13 -06:00
messages Adds debug console completion (#772) 2018-08-28 18:33:28 -07:00
schema Update debug protocol json to latest (#676) 2018-07-18 10:31:10 -07:00
__init__.py Add the debugger_protocol package (and schema subpackage). 2018-01-10 22:13:01 +00:00
_base.py Add Readonly and WithRepr. 2018-02-01 16:50:09 +00:00
README.md Add a README about the debugger protocol. 2018-02-06 18:30:24 +00:00

VSC Debugger Protocol

Visual Studio Code defines several protocols that extensions may leverage to fully integrate with VSC features. For ptvad the most notable of those is the debugger protocol. When VSC handles debugger-related input via the UI, it delegates the underlying behavior to an extension's debug adapter (e.g. ptvsd) via the protocol. The debugger_protocol package (at which you are looking) provides resources for understanding and using the protocol.

For more high-level info see:

Protocol Definition

The VSC debugger protocol has a schema which defines its messages. The wire format is HTTP messages with JSON bodies. Note that the schema does not define the semantics of the protocol, though a large portion is elaborated in the "description" fields in the schema document.

Components

Participants

The VSC debugger protocol involves 2 participants: the client and the debug adapter, AKA server. VSC is an example of a client. ptvsd is an example of a debug adapter. VSC extensions are responsible for providing the debug adapter, declaring it to VSC and connecting the adapter to VSC when desired.

Communication

Messages are sent back and forth over a socket. The messages are JSON-encoded and sent as the body of an HTTP message.

Flow:

Message Types

All messages specify their type and a globally-unique monotonically-increasing ID (seq).

The protocol consists for 3 types of messages:

  • event
  • request
  • response

An event is a message by which the debug adapter reports to the client that something happened. Only the debug adapter sends events. An event may be sent at any time, so the client may get one after sending a request but before receiving the corresponding response.

A request is a message by which the client requests something from the debug adapter over the connection. That "something" may be data corresponding to the state of the debugger or it may be an action that should be performed. Note that the protocol dictates that the debug adapter may also send requests to the client, but currently there aren't any such request types.

Each request type has a corresponding response type; and for each request sent by the client, the debug adapter sends back the corresponding response. response messages include a request_seq field that matches the seq field of the corresponding request.

Tools related to the schema, as well as a vendored copy of the schema file itself, are found in debugger_protocol/schema. Python bindings for the messages are found in debugger_protocol/messages. Tools for handling the wire format are found in debugger_protocol/messages/wireformat.py.

Using the Python-implemented Message Types

The Python implementations of the schema-defined messages all share a ProtocolMessage base class. The 3 message types each have their own base class. Every message class has the following methods to aid with serialization:

  • a from_data(**raw) factory method
  • a as_data() method

These methods are used by the wireformat helpers.

Other Resources