How to fix pip ModuleNotFoundError (No module named pip._internal.utils.temp_dir) by avoiding pipx vs virtualenv mix-ups

Fix pip ModuleNotFoundError from pipx/venv path mix-ups (No module named pip._internal.utils.temp_dir). Activate the venv and upgrade pip with python3 -m pip.

Running a Python app and suddenly getting a ModuleNotFoundError from pip is irritating, especially when you’re confident the environment is set up correctly. A typical case looks like pip attempting to import its own internals and failing from an unexpected location, which often hints at an environment mismatch rather than a broken package you’re trying to install.

What the failure looks like

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/__main__.py", line 22, in <module>
    from pip._internal.cli.main import main as _main
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/_internal/cli/main.py", line 11, in <module>
    from pip._internal.cli.autocompletion import autocomplete
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/_internal/cli/autocompletion.py", line 10, in <module>
    from pip._internal.cli.main_parser import create_main_parser
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/_internal/cli/main_parser.py", line 9, in <module>
    from pip._internal.build_env import get_runnable_pip
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/_internal/build_env.py", line 23, in <module>
    from pip._internal.utils.temp_dir import TempDirectory, tempdir_kinds
ModuleNotFoundError: No module named 'pip._internal.utils.temp_dir'

Environment details at the time showed Python 3.12.3 and pip 25.1.1 inside a virtual environment. There was also an attempt to install packages like moviepy and companions using a direct call to the venv’s Python interpreter, and a separate call to ensurepip reporting pip as already installed. The install command looked like this:

xxx:~$ $HOME/.venvs/MyEnv/bin/python -m pip install moviepy SpeechRecognition pydub pysrt googletrans==4.0.0-rc1 gtts

What’s actually going wrong

The stack trace makes it clear that the import path for pip is resolving into a pipx-managed location: /home/mel/.local/share/pipx/shared/lib/python3.12/site-packages. That means the process that tried to use pip wasn’t running in the intended virtual environment context. In parallel, there was inconsistency in invoking the interpreter (mixing python and python3) and an unnecessary detour through ensurepip. The core of the issue is not moviepy itself but pip being imported from a different environment than the one where your packages live.

How to fix it

The resolution was straightforward once the right environment was in control. First, activate the virtual environment so that both the interpreter and pip are pulled from that venv. Then remove the previously installed moviepy in that environment, upgrade pip from inside the same environment, and reinstall moviepy. Concretely, the successful sequence was to activate the venv, uninstall moviepy, run a pip upgrade from the environment, and install moviepy again.

Upgrading pip from the active environment:

python -m pip install --upgrade pip

If you prefer using the explicitly versioned interpreter, the same upgrade pattern can be run as:

python3 -m pip install -U pip

With pip up to date in the correct environment, re-run your package install with the environment’s interpreter, for example:

xxx:~$ $HOME/.venvs/MyEnv/bin/python -m pip install moviepy SpeechRecognition pydub pysrt googletrans==4.0.0-rc1 gtts

One more practical point that helped: keep using python3 consistently across commands so you don’t accidentally target a different interpreter binary.

Why this matters

Mixing tools or interpreters across system Python, pipx, and venvs tends to create ghost failures like missing internals, where pip gets imported from a location that wasn’t meant for the current run. Ensuring that every step—upgrade, uninstall, install—executes within the same virtual environment prevents cross-contamination of paths and makes diagnostics reliable. It also avoids chasing the wrong problem; here, the exception was about pip internals, not about moviepy.

Takeaways

Always activate the virtual environment before installing or upgrading anything so the correct site-packages path is in use. Use a consistent interpreter prefix like python3 -m pip to keep control over where pip operates. When you see pip resolving from a pipx path in the traceback but you intended to use a venv, stop and fix the context first. If a package install goes sideways, a clean uninstall, pip upgrade in the active environment, and a reinstall is often the shortest path to green.