ImportError: No module named 'requests' in venv – real fix

What's actually happening

You've got a virtual environment active, your script looks fine, but Python just won't find requests. The error: ImportError: No module named 'requests'. This almost always means one thing: the requests package isn't installed in the environment you're currently using. It's not a Python version mismatch or a broken PATH — it's a missing package. Period.

Let's fix it. Start with the fastest fix. Stop when it works.

Fix 1: Quick pip install (30 seconds)

This works 90% of the time if you already have your venv activated. Run:

pip install requests

That's it. But wait — you need to be sure you're installing it into the right place. Here's the gotcha: if you installed Python globally and your venv is a different Python version, pip might point to the global one. Verify you're inside your venv by checking the prompt — you should see (venv) at the start. If not, activate it first:

# On Windows:
venv\Scripts\activate

# On macOS/Linux:
source venv/bin/activate

Then run pip install requests. Test it with python -c "import requests; print('ok')". If you see ok, you're done. If you still get the error, move to Fix 2.

Why this might fail

If you used pip3 instead of pip, or if your venv uses Python 3.10 but your global pip installs to Python 3.9, the package ends up in the wrong place. Always use python -m pip to be explicit:

python -m pip install requests

This ensures you use the same Python interpreter that's tied to your venv.

Fix 2: Check and rebuild requirements (5 minutes)

If Fix 1 didn't work, something's off with your environment. Start by checking what's installed:

pip list

If you see requests in the list but the import still fails, you likely have a corrupted install or a version conflict. Force reinstall it:

pip uninstall requests -y
pip install requests

Still broken? Check if your venv is using the right Python:

which python   # macOS/Linux
where python   # Windows

The path should point inside your venv folder, like /home/user/project/venv/bin/python. If it points to /usr/bin/python or C:\Python310\python.exe, your venv isn't active. Deactivate it and reactivate it cleanly:

deactivate
# Wait for prompt to lose the (venv) prefix
# Then activate again
source venv/bin/activate

Now run pip list again. If requests still isn't there, install it. If it IS there now, your previous activation was stale.

The requirements.txt trick

If you're working with a team or a project that has a requirements.txt, run this to install everything fresh:

python -m pip install -r requirements.txt

This ensures you don't miss any dependencies. Sometimes requests depends on urllib3, and a broken chain can cause the import to fail. Reinstalling from requirements fixes that.

Fix 3: Nuke and rebuild the virtual environment (15+ minutes)

This is the nuclear option. Use it when your venv is so broken that even reinstalling packages fails — maybe you deleted files, upgraded Python in place, or have permission issues. Don't bother debugging further. Just rebuild.

First, capture your current packages (if you can):

pip freeze > requirements.txt

If pip freeze fails, you'll need to reconstruct requirements manually. Annoying, but sometimes that's the price of a broken environment.

Now delete the venv folder:

# macOS/Linux
rm -rf venv

# Windows PowerShell
Remove-Item -Recurse -Force venv

Then recreate it with the same Python version you were using:

python -m venv venv

Activate it and install from your saved requirements:

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

Test it: python -c "import requests; print('ok')". This time it will work, provided you actually had the package name right in your requirements file.

When this still fails

If after a clean rebuild you still get No module named 'requests', check two things:

• Python version mismatch: Did you create the venv with Python 3.11 but the system's python3 points to 3.9? Use explicit versions: python3.11 -m venv venv.
• Network issues: Your pip couldn't download the package. Check if you're behind a corporate proxy. Set HTTP_PROXY and HTTPS_PROXY environment variables.

One last thing — the Pycharm or VS Code trap

Sometimes the terminal shows the right venv, but your IDE is using a different Python interpreter. In VS Code, check the bottom-left corner — it shows the interpreter path. Click it and select the one inside your venv. In PyCharm, go to Settings > Project > Python Interpreter and set it to your venv's python.exe or bin/python.

The real cause is almost always that the interpreter you're running the script with doesn't have the package. You just need to align them.

That's it. Start with Fix 1, skip the rest if it works. No need to overthink.