Skip to main content
Pitfall

Two Python venvs, two different silent-failure modes

Symptom​

Scripts that should work produce confusing errors, or fail silently, depending on which terminal session you happen to be running them from — with no obvious connection between the symptom and the actual cause.

Environment​

  • G1 EDU Orin NX, an earlier build era (pre-JP6.2, Python 3.8 platform ceiling)
  • Two required, incompatible virtual environments on the same machine

Root Cause​

This project's earlier build era required two separate venvs that could not be merged, because their dependency requirements were genuinely incompatible on the JetPack 5.1.1 / Python 3.8 platform:

VenvPythonPurpose
Voice pipeline venv3.8.10Voice pipeline only
SDK/gesture venv3.10Robot SDK2, dance/gesture pipeline, direct arm control

Running an SDK script from the voice-pipeline venv — or vice versa — doesn't always fail loudly. Sometimes it does. Often it produces a confusing, unrelated-looking error, or silently no-ops, because the wrong Python version has some but not all of the required packages available, just enough to get partway through before failing in a way that doesn't point back to "wrong venv" as the cause.

Fix​

No real fix beyond discipline and a checked habit, given the platform constraint at the time — the two venvs genuinely couldn't be unified until the JetPack 6.2 migration removed the Python 3.8 ceiling entirely (see the JP6.2 reflash log entry). The practical mitigation:

# ALWAYS check which venv is active before running ANY script
python --version

Treat this as a mandatory first line of every session, not an occasional sanity check — the failure modes from running in the wrong venv are inconsistent enough that "it usually works" is not a safe signal.

Where this stands now​

Post-JP6.2, this is resolved architecturally rather than by discipline: Python 3.11 supports both the SDK and Pipecat in a single venv, so the two-venv split — and the whole class of "wrong venv" silent failures — no longer applies to the current stack. Documenting it here anyway, since anyone working with G1 EDU on an older JetPack/Python ceiling will hit exactly this.

Time cost: Not a single large cost — more a recurring background tax of a few minutes lost per incident, across many sessions, until the venv-check habit became automatic.