Fix ModuleNotFoundError: No module named 'requests' in venv

Cause #1: You haven't installed requests inside the virtual environment

This is the most common case. You created a virtual environment, activated it, but then you ran pip install requests outside the venv. Or you never installed it at all. The error message is Python's way of saying, "I looked in this environment's site-packages and requests isn't there."

Here's the fix. First, make sure you're actually in the venv. Your terminal prompt usually shows (venv) at the start. If not, activate it:

# Linux/Mac
source venv/bin/activate

# Windows
venv\Scripts\activate

Once activated, install requests:

pip install requests

Then run your script again. If you still get the error, verify where pip is installing to:

which pip   # Linux/Mac
where pip   # Windows

The path should point inside your venv folder. If it shows something like /usr/bin/pip or /usr/local/bin/pip, you're not actually in the venv. Re-activate it and try again.

One gotcha: on some systems you have to use python3 -m pip instead of pip, especially if you have multiple Python versions. That command guarantees you're installing for the same interpreter that runs your script.

Cause #2: You're using a different Python interpreter than the one in your venv

This one tripped me up when I first started. You're inside the venv, you install requests, but when you run python script.py it still fails. Why? Because the python command on your system isn't pointing to the venv's Python.

This happens when the venv was created with a different Python version than the one in your PATH. For example, you create a venv with Python 3.9, but your system's python points to Python 3.8. The venv is tied to the interpreter it was created with.

Check which Python you're using:

which python   # Linux/Mac
where python   # Windows

It should show something like /path/to/venv/bin/python. If it doesn't, you need to either:

• Activate the venv correctly (see Cause #1)
• Explicitly run the venv's Python interpreter: ./venv/bin/python script.py

Be careful when you have both python and python3 commands. On many systems, python points to Python 2.7, and python3 points to 3.x. If you created the venv with python3 -m venv venv, then you must run your script with python3 from inside the venv, or use the full path.

Cause #3: pip installed to the user site-packages instead of the venv

Sometimes, even when you're active in the venv, pip decides to install to the global user site-packages. This usually happens because of PIP_USER environment variable being set, or because you used --user flag out of habit.

The fix is simple. Check if PIP_USER is set:

echo $PIP_USER   # Linux/Mac

If it outputs true or 1, unset it:

unset PIP_USER   # Linux/Mac

On Windows, you'd do set PIP_USER= in cmd or Remove-Item Env:PIP_USER in PowerShell.

Then install again without the --user flag. You can verify where requests ended up:

pip show requests

Look at the Location field. It should point to the venv's site-packages directory. If it shows something like ~/.local/lib/python3.x/site-packages or C:\Users\You\AppData\Roaming\Python\Python3x\site-packages, then it's going to the wrong place.

Also, check for a pip.conf or pip.ini file. Sometimes these contain a user = true line that overrides everything. On Linux/Mac, check ~/.config/pip/pip.conf or ~/.pip/pip.conf. On Windows, it's %APPDATA%\pip\pip.ini. If you see user = true, remove it or set it to false.

Quick-reference summary table

If you've tried all three and still stuck, the nuclear option is to recreate the venv from scratch. Delete the venv folder, then create it again with python3 -m venv venv, activate, and install requests. That clears up any lingering path issues.