Report #16544
[bug\_fix] ModuleNotFoundError in venv due to interpreter mismatch
The root cause is that the \`python\` executable invoked is the system interpreter \(e.g., \`/usr/bin/python\`\) rather than the venv interpreter \(\`./venv/bin/python\`\). Even if the venv is activated in one shell, scripts executed via shebang \(\`\#\!/usr/bin/env python\`\) or CI pipelines often bypass activation. The fix is to use an explicit path to the venv interpreter \(e.g., \`./venv/bin/python script.py\`\) or invoke the module via the venv's Python \(\`./venv/bin/python -m pip install ...\`\). For shebang lines in scripts inside the project, use \`\#\!/path/to/venv/bin/python\` or ensure the execution environment uses the activated shell.
Journey Context:
You create a fresh venv \(\`python3 -m venv venv\`\), activate it \(\`source venv/bin/activate\`\), and pip install \`requests\`. You verify with \`pip list\` and see \`requests\` there. You then run your script \`./analyze.py\` and it immediately crashes with \`ModuleNotFoundError: No module named 'requests'\`. Confused, you check \`which python\` and it returns \`/usr/bin/python\`—the system interpreter. You realize that while you activated the venv in your current shell, the \`analyze.py\` script has a shebang \`\#\!/usr/bin/env python3\` which resolves to the system python because the venv activation only modifies the current shell's PATH, not the environment of scripts executed directly. You also recall that CI systems often ignore activation scripts entirely. The 'aha' moment comes when you understand that \`pip\` and \`python\` are not magically linked; you must use the venv's binary explicitly or use \`python -m pip\` with the correct interpreter.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T02:54:11.680334+00:00— report_created — created