Problem: venv scripts fail with "bad interpreter: No such file or directory" after moving (python -V still works) —— Trove problem library

What you will run into

After moving the project (with its venv directory), copying it to a new machine, or changing the username path, commands inside the venv fail with bad interpreter: No such file or directory, and the old path in the error is one you stopped using long ago.

Most confusing: venv/bin/python -V still prints fine — the environment looks intact, but pip and other entry scripts all fail.

Why this happens

The venv's entry scripts (pip, accelerate, uvicorn...) have a shebang line with the absolute path at creation time (#!/old/path/venv/bin/python3).

Once the directory moves, the user changes, or the machine changes, the old path no longer exists and the kernel reports bad interpreter (exit 126).

Meanwhile venv/bin/python itself is just a symlink to the system interpreter, independent of location, so it still runs — that's the truth behind "python works, pip errors".

kohya_ss#856 is a typical case: the two paths in the error have different usernames because the project was copied from one machine's user directory to another user's.

Deterministic takeaway: the shebang path differing from the current path means the venv is stale. Two correct paths exist — recreate it (python3 -m venv .venv && pip install -r requirements.txt, the cleanest), or repair in place (python3 -m venv --upgrade .venv rewrites the shebangs).

venvs should not be committed to git, because paths differ per machine. Use requirements/lock files and rebuild instead.

Fixed diagnostic: head -1 .venv/bin/pip shows the shebang; compare it with pwd to spot the stale path.

Step by step

1. Export dependencies — Required

venv/bin/python -m pip freeze > requirements.txt

2. Delete and rebuild — Required

rm -rf venv
python3 -m venv venv

3. Reinstall dependencies — Required

venv/bin/python -m pip install -r requirements.txt

4. Rerun an entry command to confirm — Required

venv/bin/accelerate --version

No more bad interpreter means success.

5. Root fix — Required

• venv doesn't go into git; don't carry the venv along when copying projects;
• for a "movable" environment use Docker images, or uv/poetry/conda (manage environments by name, path-independent);
• when source venv/bin/activate says not found: first ls venv/bin/activate to confirm the directory was actually created (common when creation failed / was ignored by .gitignore); rebuild if missing.

How to confirm it works

venv/bin/pip --version

A normal version output means success. Measured: pip 25.1.1 fine before moving; after mv → bad interpreter (exit 126); delete-and-rebuild → pyyaml install succeeded.

Other environments

Symptom

After the project (including its venv directory) is moved, copied to a new machine, or lands under a different username path, commands from the venv fail:

sh: /Users/XXXi/VLADDiffusion/kohya_ss/venv/bin/accelerate: /Users/dflagmei/VLATDiffusion/kohya_ss/venv/bin/python: bad interpreter: No such file or directory

Key traits: the error mentions an old path you no longer use; source venv/bin/activate may also fail with No such file or directory; most confusingly, venv/bin/python -V still prints a version — the environment looks intact.

Cause

Entry-point scripts inside the venv (pip, accelerate, uvicorn, ...) have a shebang pointing to the absolute path at creation time (#!/old/path/venv/bin/python3). Once the directory moves, the user changes, or the machine changes, that path no longer exists and the kernel reports bad interpreter (exit 126). venv/bin/python itself is only a symlink to the system interpreter, independent of location, so it keeps working — that is the truth behind "python works but pip fails". activate is similar: the script uses relative references, but if the venv directory was deleted or never created, source reports the file is missing. kohya_ss#856 is the classic case: the two paths in the error have different usernames because the project was copied between user directories.

Solution

1. The right fix: delete the venv and recreate it (venvs are not guaranteed portable; do not try to patch shebangs):

• Export dependencies first: venv/bin/python -m pip freeze > requirements.txt;
• Recreate with python3 -m venv venv, then venv/bin/python -m pip install -r requirements.txt;
• Re-run the entry command to confirm.

1. Temporary workaround: venv/bin/python -m pip ... bypasses the shebang and still works (verified), but installed packages

live in the old site-packages path and must be reinstalled anyway — not a long-term solution.

1. Root fix: never commit the venv to git, never copy the venv together with the project; for "portable" environments use Docker images

or uv/poetry/conda (environments managed by name, path-independent).

1. When source venv/bin/activate reports missing: first ls venv/bin/activate to confirm the directory was actually created

(often creation failed or it is gitignored), then recreate it.