pypilot-cli

A package's requires_python is frequently a lie of omission. mediapipe 0.10.9 declares >=3.8 but only ships wheels for cp39–cp312; on 3.13 pip hunts for a sdist and dies with a metadata error that never mentions Python versions.

PyPilot reads both signals. It takes requires_python as a starting range, intersects it with the interpreter versions that actually have prebuilt wheels for your OS and CPU architecture, and repeats across every dependency in the workspace. What's left is the set of interpreters that can run the whole project. When that set is empty, it names the two packages whose constraints collide — which is the piece package-manager output never gives you.

What else it catches

• Removed APIs. mediapipe 0.10.35 installs cleanly and then dies on module 'mediapipe' has no attribute 'solutions'. PyPilot inspects the installed package on disk and flags mp.solutions in the editor instead of at runtime.
• CUDA alignment. For pip-installed frameworks the host NVIDIA *driver* decides compatibility, not the system CUDA toolkit. PyPilot reads nvidia-smi, maps the driver to its highest supported runtime, and picks the matching PyTorch index (cu124 rather than a mismatched default). No GPU falls back to CPU wheels; Apple Silicon gets MPS guidance.
• Pinned constraints. mediapipe==0.10.14 is evaluated against wheels published for that release, not the wider matrix.

Everything resolves from PyPI metadata and bundled lookup tables. No AI, no API keys, no external services.

Commands

doctor (read-only health check), setup (bootstrap a venv via uv or pip), check <pkg>, install <pkg>, fix python, fix cuda, update-data, migrate-conda (environment.yml → pyproject.toml), and lsp (the language server the editor extensions drive).

The pip package is a thin launcher: it downloads and caches the verified native Rust binary for your platform, or defers to one already on $PATH.