Fix pip Installing Into the Wrong Python Environment

If pip says a package is installed but your program raises ModuleNotFoundError, check which Python ran each command. An installation belongs to an environment. A successful install in one environment does not make the package available to another.

This guide reproduces that mismatch with two disposable environments, then checks the repair from the program's own interpreter. The commands use PowerShell on Windows and Python 3.10 or newer with venv support. For first-time environment setup and activation, use the virtual-environment course lesson.

Diagnose the existing failure first

In the terminal where your application fails, run these read-only checks. If a command is unavailable, keep that as evidence rather than installing a different global Python immediately.

Get-Command python,pip -All | Select-Object Name,Source
python -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix)"
python -m pip --version
pip --version

Compare the full paths, not just the Python version or a (.venv) prompt. Two environments can use the same Python version. python -m pip runs pip through that specific Python; a bare pip command can resolve elsewhere on PATH. If both pip commands agree but the application still fails, the editor, notebook or task runner may be using a third interpreter.

Reproduce a mismatch without changing your project

Create a new python-path-check practice folder. This example installs the small colorama package only into disposable environments. The installation step needs network access. None of these commands changes global packages or requires activation.

mkdir python-path-check
cd python-path-check
python -m venv .tools
python -m venv .venv
.\.tools\Scripts\python.exe -m pip install colorama
.\.tools\Scripts\python.exe -m pip show colorama
.\.venv\Scripts\python.exe -c "import colorama"

The last command should raise ModuleNotFoundError: No module named 'colorama'. The earlier installation succeeded in .tools, but the failing program ran in .venv. That is the entire mismatch. Exact versions and absolute paths depend on your machine.

Collect evidence from each interpreter

Save this as check_runtime.py in the practice folder. It prints the running executable and environment prefixes, asks that same interpreter for its pip location, and checks the module's origin before importing it.

from importlib import metadata
from importlib.util import find_spec
from pathlib import Path
import subprocess
import sys

print("Executable:", sys.executable, flush=True)
print("Prefix:", sys.prefix, flush=True)
print("Base prefix:", sys.base_prefix, flush=True)
print("Virtual environment:", sys.prefix != sys.base_prefix, flush=True)
subprocess.run([sys.executable, "-m", "pip", "--version"], check=True)

spec = find_spec("colorama")
if spec is None:
    raise SystemExit("FAIL: colorama is not visible to this interpreter")
origin = Path(spec.origin).resolve()
print("Module path:", origin, flush=True)
if Path(sys.prefix).resolve() not in origin.parents:
    raise SystemExit("FAIL: colorama comes from outside this environment")

import colorama

print("Installed version:", metadata.version("colorama"))
assert hasattr(colorama, "Fore"), "Unexpected module imported"
print("PASS: this interpreter imports its own installed colorama")

.\.tools\Scripts\python.exe check_runtime.py
.\.venv\Scripts\python.exe check_runtime.py

The tools run should print a module path inside .tools and finish with PASS. The project run should print a prefix inside .venv, then fail because colorama is absent. Both report a virtual environment, so that boolean alone cannot tell you that the correct one was selected.

Repair the project environment deliberately

Install with the exact interpreter that will run the program, then repeat the diagnostic with that interpreter:

.\.venv\Scripts\python.exe -m pip install colorama
.\.venv\Scripts\python.exe check_runtime.py
.\.venv\Scripts\python.exe -m pip check

Expect the module path to move inside .venv and the final line to say PASS: this interpreter imports its own installed colorama. The separate pip check should report no broken requirements in this small example. In a real project, install from its maintained requirements or project configuration instead of adding arbitrary packages until the error disappears.

Calling the interpreter directly also avoids PowerShell activation-script restrictions. On macOS/Linux the analogous executable is normally .venv/bin/python; these command blocks are specifically the Windows paths.

Match the editor and task runner

Run check_runtime.py through the editor's normal Run action and compare its executable with the passing terminal run. Select the intended interpreter in the editor if it differs, then run the same check again. A terminal that uses the right environment does not prove the editor uses it too.

For a scheduled task or script launcher, use the absolute path to the intended environment's Python and pass the application script as an argument. For a notebook, inspect sys.executable in the running kernel and select the intended kernel before installing into it. Do not repair one runtime while continuing to launch another.

When the paths agree but imports still fail

• A local file is named colorama.py: it can shadow the installed package. Inspect the reported module path, rename your own conflicting file, and restart the interpreter.
• The environment moved with the project: create a new environment beside it and reinstall from the project's recorded dependencies. Keep the existing one until the replacement passes; environments are not portable folders.
• pip is missing: confirm the intended interpreter first. Repair pip for that environment using its supported installation method rather than switching silently to a different pip.
• Global or user-site paths appear: check whether system site packages or PYTHONPATH were intentionally enabled. The practice environments here use normal isolated defaults.

Try a successful import from the wrong place

After the repaired run passes, create an empty colorama.py beside check_runtime.py and rerun the check. Does the package installation disappear?

Answer: no. The installed distribution remains, but the local filename takes precedence for this script launch. The probe prints that local path and fails its environment-origin check. Rename the practice file to color_notes.py and rerun in a fresh process. Reinstalling the same package cannot fix a local name collision.

References: Python virtual environments and running pip through a selected interpreter.