Python venv “Module Not Found” Despite pip install

Getting a “module not found” error right after running pip install for that exact module is one of the most confusing Python errors, precisely because it looks impossible — you just installed it, so how can it not be found? The answer is almost always that the install and the run are happening in two different Python environments.

The Problem

You run pip install requests, it completes successfully with no errors, but running your script immediately after still fails with:

ModuleNotFoundError: No module named 'requests'

Running pip install requests again shows Requirement already satisfied, confirming pip genuinely believes the package is installed — which means the problem isn’t the installation itself, but which Python interpreter is actually running your script.

Why It Happens

Python and pip can silently point to different environments, especially with virtual environments involved. The most common causes are:

• The virtual environment isn’t actually activated when you run pip install, so the package installs into your global/system Python instead of the venv — and then your script is run with the venv’s Python, which never saw that install
• The opposite situation: the package installed correctly into the venv, but the script is being run with a system-wide python command that isn’t actually pointing at the venv’s interpreter
• Multiple Python versions are installed on the machine (e.g. Python 3.10 and 3.12), and pip resolves to one version while python resolves to another, so they’re managing completely separate site-packages directories
• An IDE (VS Code, PyCharm) is configured to run your script with a different interpreter than the one selected in its integrated terminal, so installs done through the terminal don’t reach the interpreter the IDE actually uses to run the file

The Fix

First, confirm which Python interpreter is actually active, and compare it against where the package was installed:

which python
which pip
python -m site

If you’re using a virtual environment, always activate it before installing anything, and confirm the prompt reflects that it’s active (usually shown as a prefix like (venv) in your terminal):

# macOS/Linux
source venv/bin/activate

# Windows (PowerShell)
venv\Scripts\Activate.ps1

Once activated, verify pip and python both point inside the venv directory, not to a system-wide install:

which python
# should show a path inside your venv folder, like /path/to/project/venv/bin/python

A more reliable way to guarantee the install and the run use the same interpreter is to invoke pip through Python explicitly, rather than relying on whichever pip command happens to be first in your system PATH:

python -m pip install requests

This ties the install directly to whichever python command you’re about to use to run your script, removing the ambiguity of a separate pip binary potentially pointing elsewhere.

If you’re using an IDE, explicitly check and set its configured interpreter to match your virtual environment, rather than assuming it automatically picked up the same one your terminal is using — this is a very common source of exactly this symptom, especially right after creating a new venv.

Still Not Working?

If everything above checks out and the interpreter paths match, but the error persists, check for a naming collision — a local file in your project directory named the same as the package you’re trying to import (for example, a file called requests.py in your own project) will shadow the real installed package, since Python looks in the current directory before searching installed site-packages.

It’s also worth checking whether the package was installed with the --user flag at some point, which installs into a per-user site-packages directory that’s separate from both your system Python and any virtual environment. A package installed this way can appear present when checking outside a venv, but remain invisible once a venv (which by default doesn’t inherit user-site packages) is activated:

python -m site --user-site

If your virtual environment was created with the --system-site-packages flag, it behaves differently than a normal isolated venv, since it can see globally installed packages in addition to its own. This is sometimes intentional, but if you’re not sure whether your venv was created this way, it’s worth checking, since the presence or absence of this flag changes which “not found” scenarios are even possible in the first place:

cat venv/pyvenv.cfg
# look for: include-system-site-packages = true/false

Finally, on projects using tools like Poetry or Pipenv instead of a plain venv, remember that these tools manage their own virtual environments separately from anything created manually with python -m venv. Running a bare pip install outside of poetry add or pipenv install can install into the wrong environment entirely, even if a venv-style folder is technically active in your shell, since these tools track dependencies through their own lock files rather than relying purely on whatever environment happens to be currently activated.