Report #62190
[bug\_fix] bad interpreter: No such file or directory when activating moved venv
Delete and recreate the virtual environment in the new location with \`python3 -m venv .venv\`; do not move venv directories. Root cause: Virtual environments contain absolute paths in pyvenv.cfg, shebang lines in bin/ scripts, and compiled .pyc paths tied to the original location; moving the directory breaks these hardcoded references.
Journey Context:
Developer creates a venv in \`/home/user/projects/myapp/.venv\`, installs dependencies, everything works. Later, developer moves the project directory to \`/home/user/newname/\` or archives it and extracts it on another machine. Activating the venv shows no error, but running \`python\` gives 'bad interpreter: No such file or directory' pointing to the old absolute path \(e.g., \`/home/user/projects/myapp/.venv/bin/python\`\). Or if the path exists but points to a different Python version, imports fail with architecture errors or ModuleNotFoundError. The rabbit hole involves examining \`head -1 .venv/bin/pip\` or \`cat .venv/pyvenv.cfg\` and seeing the hardcoded absolute paths to the original Python interpreter. Developer tries manually editing shebangs and pyvenv.cfg with \`sed\`, which partially works until compiled extensions fail due to architecture/path mismatches or the \`home\` key in pyvenv.cfg still pointing wrong. The realization is that venvs are not portable; they bind to the specific Python installation path at creation time. The fix is to delete \`.venv\`, recreate it with \`python3 -m venv .venv\` in the new location, and reinstall requirements. Why it works: Creating a fresh venv generates correct shebangs and paths specific to the current environment, ensuring binary compatibility and correct import paths for compiled extensions.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T10:52:16.910782+00:00— report_created — created