You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would the maintainers welcome a Python SDK contribution?
MXC currently provides Rust, .NET, and Node SDKs. A Python SDK would let Python-based AI tools use MXC’s execution, discovery, and process lifecycle APIs directly, without building their own executor wrapper.
I would like to contribute the Python integration and functional tests. I have reusable Windows process-management code and regression scenarios from Masters’ Nudge 0.6.4 and 0.6.5 that could support this work.
Proposed technical implementation details
The proposed direction is to use the existing mxc_ffi C ABI, consistent with the Node and .NET SDK architecture. Containment and enforcement would remain in MXC.
For an initial scope, I suggest:
Host/backend discovery and process execution.
Standard streams, exit results, timeouts, explicit termination, and cleanup.
Cancellation and resource ownership consistent with existing SDK contracts.
I can begin functional validation on Windows 11 x64. Supported platforms, packaging, and the API scope would need agreement during design review.
Candidate regression scenarios include caller termination, timeout, cancellation, partial launch failure, descendants holding output handles open, and workloads that never read standard input. Existing MXC coverage should be reused where applicable.
If this direction is useful, I would prepare the required design and API proposal after scope acceptance, before implementation.
Hi Branden Bonaby (@bbonaby), thanks for triaging this! Does the proposed scope look reasonable to the team, and would a documentation-only PR with the design and API proposal be the right next step? I’m happy to start smaller if you’d prefer.
Activity
shihchengwei-lab commentedon Nov 3, 2026
Hi Branden Bonaby (@bbonaby), thanks for triaging this! Does the proposed scope look reasonable to the team, and would a documentation-only PR with the design and API proposal be the right next step? I’m happy to start smaller if you’d prefer.