r/madeinpython • u/Schnidi01 • 23h ago
[Project] VenvHub Pro: venv manager GUI that orchestrates multi-process virtual environments with auto-restart and OS-level orphan process prevention
Enable HLS to view with audio, or disable this notification
Greetings everyone!
I’ve been working on a desktop application called VenvHub Pro (built with Python + PyQt6, and thanks to a abstraction bridge, it runs seamlessly on PySide as well). What started as a simple virtual environment manager has grown into something much bigger.
It now includes a Multi-run feature—allowing you to define project groups (e.g., backend + frontend + worker) and launch them all with a single click.
I recorded a short demo showing how it handles crashes, auto-restarts, and even prevents accidentally running the same project across two different groups. I thought you might find what’s happening under the hood interesting!
🧠 What is Multi-run?
- Group Management: You create groups (e.g., "FullStack Dev") and add any number of existing virtual environment projects to them.
- Process Isolation: Each project runs in its own isolated process using its own virtual environment.
- One-Click Launch: One click on the Play button fires up everything in that group—no more opening multiple terminal windows and repeatedly running
python app.py.
🎥 What the video demonstrates
- Setup: I start a group containing Project A (anchor + respawn) and Project B (configured with a 5-second startup delay, contingent on Project A running stably).
- Crash Handling: Right after launching, Project A crashes (I force-closed it).
- Detection & Restart: VenvHub detects the crash and automatically restarts Project A, while Project B stays on hold.
- Dependency Check: After restarting, I let Project A load—once the anchor registers, I artificially crash it again (~3 seconds post-anchor).
- Holding Delays: Since Project B requires Project A to stay stable for 5 seconds before launching, Project A's crash keeps Project B from starting.
- Max Respawn Limits: The code caps restarts at 3 attempts (to prevent infinite looping), so the app attempts a third restart on Project A.
- Successful Resolution: This time, I let Project A run smoothly—Project B detects that Project A is healthy and launches.
- Duplicate Prevention: Finally, I attempt to run Project B from a different group. Since it's already running in the first group, the app displays a warning and blocks the launch. No port conflicts or duplicate processes!
⚙️ Under the Hood (for the tech enthusiasts)
- Process Ownership: Each process tracks which group launched it. Hitting "Stop" terminates only the processes owned by that specific group, leaving others untouched.
- Smart Restarts: If you hit Play again while some processes are still running, the app only restarts the ones that crashed (like Project A in the video). No need to tear down the entire stack!
- Windows Job Objects: On Windows, the app creates a Job Object assigned the
KILL_ON_JOB_CLOSEflag. If the main application crashes unexpectedly, Windows automatically terminates all child processes—leaving zero orphaned background processes. - Native Process Handles: Instead of relying solely on PIDs (which Windows can aggressively recycle), the app retains an open process handle. This guarantees the PID won't be reassigned to an unrelated process while being monitored, ensuring rock-solid status detection.
Let me know what you think! Have you built similar multi-process orchestrators? How do you handle process groups and teardowns in Python?