Hello.
After hours, I’ve been developing a Python 3.8.20+ (because of uv support) wrapper for the TestStand COM API (I am trying to fill the "legacy code" gap by using modern astral.sh Rust-based stack for managing project iself). The main goal is a big range of both Windows OS, because of Python syntax compatibility, and engine version compatibility (automation of maintenance for both old and new setup/test stations).
It is designed as a twin API, meaning that if someone is already familiar with the codebase (LabVIEW palette module calls/.NET Interop API calls), they should find it intuitive and easy to match official NI API reference documentation (which is not copyrighted, of course) with extra Pythonic "flavors/sugarifiers."
I would prefer to use it for simple R&D tooling like managing custom data types, creating macros for inserting LabVIEW adapter steps, creating simple analyses for maintenance purposes (like finding obsolete modules and updating via prototypes / adapter step properties manipulation), sniffing UI messages (like creating loggers for HMIs), and [de]serializing PropertyObjects to more common formats as JSON because of dictionary integration.
In the past I was experimenting with optional wxPython integration for user interfaces, but too many headaches with the scale; better to create a UI language agnostic way and server-engine layer independently in my opinion, but for now I am focusing only on a headless approach (for graphical one I am use some tweaks in higher level logic for proper handling Message Popups, but I am aware to not "bloat" wrapper with that). https://github.com/TheDomcio/py-teststand - they are examples for coverage of the core tested (not just API documentation based dumps) functionality. Feel free for feedback, but I am only experienced with the mentioned TestStand APIs/tooling (as my main workplace stack is LabVIEW (for both front-end and back-end) + TestStand ) and using .NET/Python for support utils/modules.
Note: Also I had good experience with cx_Freeze support for creating self-contained executables with toolings based on the project for easier distribution; in most cases, you need just add some configuration to pyproject.toml, as newer versions of cx_Freeze slightly reduce need of creation setup/build modules.
