WIP: Add Python runtime environments#2704
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
❌ 2 Tests Failed:
View the full list of 2 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
…ixes Auto-fixes for cc/feat/venv-worker
Greptile SummaryThis PR adds isolated Python runtime environments for module workers. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (3): Last reviewed commit: "fix: launch runtime workers from prepare..." | Re-trigger Greptile |
|
|
||
| The implementation may run: | ||
|
|
||
| - in the local Python worker environment, |
There was a problem hiding this comment.
as discussed, keep local python worker intact for now. their lightweight envelope works really good
| blueprint=go2_stack, | ||
| targets={"robot": ssh_target("go2")}, | ||
| assignments={ | ||
| MLSPlannerNative: "robot", |
There was a problem hiding this comment.
we are referencing the execution target profile, should it also be part of the deployment object?
| The wrapper declares: | ||
|
|
||
| ```python | ||
| class MLSPlannerNativeConfig(NativeModuleConfig): |
There was a problem hiding this comment.
should we come up with a basic shape of our new deployed module config? which works universally on native module and packaged python module (actually I want to unify them as they are eseentially the same in terms of lifecycle, just python don't have compilation)
Problem
Python modules currently run in the coordinator environment, which forces module-specific dependency stacks into
dimos runand makes modules with complex or conflicting dependencies difficult to deploy safely.Closes N/A
Solution
Adds Python runtime environments for isolated module workers:
examples/dimos-demo-worker-module/with a runnable script showing main venv → isolated worker venv execution.Runtime structure
flowchart TD BP[Blueprint] --> MC[ModuleCoordinator] BP --> RP[RuntimePlacement<br/>Contract -> runtime + implementation] BP --> RR[RuntimeEnvironmentRegistry<br/>runtime name -> Runtime Project] MC --> Recon[Runtime Reconciliation<br/>uv/pixi locked sync] Recon --> Venv[Prepared Runtime Project venv<br/>.venv/bin/python] MC --> WMP[WorkerManagerPython] subgraph Existing["Existing default Python module path"] WMP --> DefaultPool[Default Python Worker Pool] DefaultPool --> Fork[ForkserverWorkerLauncher] Fork --> PyWorkerA[python_worker._worker_entrypoint] PyWorkerA --> ContractA[Module class instantiated directly] end subgraph New["New runtime-placed Python module path"] WMP --> RuntimePool[Runtime Python Worker Pool<br/>one pool per runtime] RuntimePool --> Cmd[CommandWorkerLauncher] Cmd --> PreparedPython[prepared .venv/bin/python] PreparedPython --> Entrypoint[venv_worker_entrypoint] Entrypoint --> PyWorkerB[python_worker._worker_entrypoint] PyWorkerB --> ContractB[Module Contract identity] PyWorkerB --> Impl[Runtime Implementation subclass] Impl --> Deps[Runtime-only dependencies] end RP --> WMP RR --> WMP Venv --> Cmd ContractB -. "RPC / streams / refs use contract identity" .-> MCRuntime placements do not replace the existing Python worker path. They add a second dispatch path inside
WorkerManagerPython: unplaced modules continue through the default forkserver pool, while placed Module Contracts are routed to a runtime-specific Python Worker Pool launched from the Runtime Project's prepared venv.Broader direction
This PR is the first concrete backend for a broader runtime-placement model: DimOS keeps a stable Module Contract in the blueprint graph, while execution can move into a backend-specific runtime.
flowchart TD Goal[End goal: remotely deployable, mixed-language DimOS modules] Seam[Stable seam introduced here<br/>Module Contract + RuntimePlacement + Python Worker Pool] Today[This PR<br/>Local locked Python Runtime Project] Remote[Future<br/>Remote Python Runtime Project<br/>SSH/container/robot-side venv] Native[Future<br/>Native Module Runtime<br/>Rust/C++ process + native SDK] Goal --> Remote Goal --> Native Remote --> Seam Native --> Seam Seam --> Today Today --> Contract[Dependency-light Module Contract] Today --> Impl[Runtime Implementation subclass] Today --> Venv[Prepared .venv/bin/python] Today --> SameSurface[Same DimOS RPC / streams / lifecycle surface]The immediate feature is local Python dependency isolation. The longer-term value is the separation between what DimOS sees and where the module runs. That same seam is what remote Python workers and native module runtimes can reuse without changing blueprint-level module identity.
Key tradeoffs:
How to Test
Expected: prints the repo/main Python executable, a worker Python executable under
examples/dimos-demo-worker-module/.venv/, runtime-only dependency outputRuntimeDependency, andworker result: demo-runtime:HELLO FROM MAIN VENV.Contributor License Agreement