Available Python modules in NVDA's runtime environment

[bramd]

For addon developers, it is nice to know which Python modules are available in NVDA's Python runtime environment. This may very between releases and is not usually documented in the changelog. This is understandable, since some dependencies of dependencies may change and it is hard to keep track of all of this. Two recent examples I encountered while bringing in a third party library to facilitate communication with a BLE (Bluetooth Low Energy) braille display that does not support Bluetooth classic and so does require totally different APIs than the normal Bluetooth APIs that we support in core:

• Asyncio: Since the Windows RT APIs use async callbacks extensively, the best Python bindings to use these were written using Asyncio. Asyncio is present in NVDA 2024.1 and 2024.2, but not in 2023.3. Based on the source code it is hard to determine why it was added. And of course it can be removed in a future version without notice.
• My dependency imported the typing_extensions module for one type definition. This module is added as an indirect dependency in 2024.2, but is missing in 2024.1 Since this was just one type, I could easily backport this and run it on 2024.1.

I would like to see a list of Python modules that may be expected in the NVDA runtime environment. So as an addon author, you know to bundle your own specific version for everything that is not in the list. I would like to know how other addon devs and NVAccess think about this.

[CyrilleB79]

And of course it can be removed in a future version without notice.

See #15886 for more context.

NV Access has not completely clarified compatibility issues that can arise so your question is relevant.

[bramd]

See #15886 for more context.

I missed that issue while looking into this, thanks for the pointer. I'm also open to other ideas being mentioned in that issue such as a dependency management system for addons (including dependencies on standard library modules) and more robust tools to properly reference modules. Now I've patched the dependency I use to work with relative imports so I can avoid adding it to the pythonpath, since I know the risks and would like to keep my dependencies contained to my addon.

I'm also setting up Github Actions infrastructure to test on multiple NVDA versions to hopefully catch these problems earlier in the future.