Public API for Access Token and Port

[jborean93]

Hi

Part of enabling support for debugging Ansible modules written in Python through debugpy we've come across a question around what is considered public API and safe to use officially.

We use two things which aren't officially documented as public APIs:

• The --adapter-access-token when launching a sub process explicitly through python -m debugpy ... (debugpy.connect() does have it documented as a kwarg)
• We find the port and access token of the currently launched Python process through to use when launching sub processes to attach back

from debugpy.server import cli as _debugpy_cli

access_token = _debugpy_cli.options.adapter_access_token
port = _debugpy_cli.options.address[1]

An alternative approach is to parse the sys.argv ourselves to store the value but --adapter-access-token isn't officially documented and it is a bit more complicated to do so than just accessing the CLI args that have been parsed into options from debugpy itself.

Is there a recommended approach you would have here, if not can we look at making a public API so we aren't relying on implementation details here? Just for some background information our current approach to adding support for debugpy is with ansible/ansible#85476.

[rchiodo]

I think the best thing to do would be to document/make public the --adapter-access-token. Not sure why it isn't documented

[rchiodo]

The access token is supposed to be private to the session, so maybe that's why it's not public, but that seems like a weak reason given you can find it in the private members. We could just expose the well known options I'd think.

[jborean93]

Sounds good, is that something you want to work on? I can look into it but my approach would be to essentially expose the cli Options in a similar way that debugpy.server.api functions are.

[rchiodo]

Sorry but I'm unlikely to get to anything like this for months, if ever. Debugpy is in my "don't let it die, but don't actually work on it" list.

[jborean93]

No worries, I'm happy to do the work considering we are the ones going to use it I just didn't know if you preferred to keep public API changes to a maintainer or not.

I've opened #1927 to document --adapter-access-token and I'll look at a subsequent PR to expose the CLI options through a public API as well.

[jborean93]

Also opened #1928 which provides a potential new public API that can retrieve this information. I tried to re-use the Options class but found it difficult to do so while also exposing it through a public annotated type and without affecting the existing arg parsing code. In the end making a frozen dataclass copy was the easier option and keeps it more of a snapshot allowing us to add/remove any options we don't think should be exposed.