Photo by Hitesh Choudhary on Unsplash

I had a solid two hours of my life taken from me because of this. I had a virtual environment set up, activated it, ran pip install requests, and watched it install successfully. Then I opened my script, tried to import it, and Python looked at me like I'd lost my mind. ModuleNotFoundError. Every time. The package was "installed" but nowhere my project could actually see it.

Here's the thing — this is one of those errors that tricks you because nothing looks wrong on the surface. pip says it worked. No red text. No angry stack trace. Just a clean install message and then total silence when your code tries to use the package. I've seen this destroy entire afternoons for people who are otherwise competent developers. The venv is activated, pip runs, the world should be fine. Except it isn't.

The problem is almost never pip itself. It's almost always about which pip you're actually running and which Python interpreter your project is talking to. Those two things not matching is the root of basically every venv-related pip headache I've encountered.

What the error actually looks like

# You run this
pip install requests

# Looks successful
Successfully installed requests-2.31.0

# Then in your script or Python shell
import requests
# ModuleNotFoundError: No module named 'requests'

# Or sometimes pip itself just refuses
ERROR: Could not find a version that satisfies the requirement virtualenv
ERROR: No matching distribution found for virtualenv

# Or the classic
bash: pip: command not found

Sound familiar? Right. Let's get into why this actually happens.

Photo by Rubaitul Azad on Unsplash

Your virtual environment isn't actually activated (or it deactivated silently)

Honestly, this is the answer 70% of the time. Your venv looks activated. Your terminal prompt might even show the environment name in parentheses. But something went sideways — maybe you opened a new terminal tab, maybe a script changed your shell environment, maybe you just forgot. When you run pip without the venv active, you're installing into your system Python or some other interpreter entirely.

Check this first:

# On Mac/Linux, check which pip you're actually using
which pip
which pip3
which python

# On Windows
where pip
where python

If the path doesn't point into your project's venv or .venv folder, you're using the wrong one. Full stop. Activate the environment and check again:

# Mac/Linux
source venv/bin/activate

# Windows CMD
venv\Scripts\activate.bat

# Windows PowerShell
venv\Scripts\Activate.ps1

After activation, which pip should return something like /your/project/path/venv/bin/pip. If it does, you're good. Run the install again.

Photo by Markus Spiske on Unsplash

pip is pointing to the wrong Python interpreter entirely

This one is sneaky. You can have your venv activated and still have pip installing to the wrong place if you have multiple Python versions on your machine. I've hit this on machines with Python 2, Python 3.9, and Python 3.11 all coexisting. A disaster.

The bulletproof fix is to stop using the bare pip command and call it through the specific Python interpreter you want:

# Instead of this
pip install requests

# Do this — it guarantees you're using the right interpreter
python -m pip install requests

# Or be even more explicit
python3 -m pip install requests

# Check which python you're calling first
python --version
python3 --version

The python -m pip pattern has saved me so many times I basically default to it now. It removes all ambiguity about which pip is running because you're explicitly telling it which Python to use. Make this a habit. Seriously.

The virtual environment itself is broken or was created with the wrong Python

Sometimes the venv is just bad. It happens more than people admit. Maybe it was created with a Python version that got uninstalled. Maybe the path moved. Maybe something corrupted it. Whatever the reason, the cleanest move is to nuke it and start fresh.

# Delete the old environment
rm -rf venv          # Mac/Linux
rmdir /s /q venv     # Windows CMD

# Create a fresh one, explicitly specifying your Python version
python3.11 -m venv venv    # or whatever version you need
python3 -m venv venv       # if you just want the default python3

# Activate it
source venv/bin/activate   # Mac/Linux
venv\Scripts\activate      # Windows

# Verify everything looks right
which python
which pip
python --version

# Now install
pip install requests

I know it feels like giving up, but recreating the venv takes maybe 30 seconds and saves you from chasing phantom bugs for an hour. I've talked myself out of doing this too early way too many times. Don't do that.

Fallback: check your pip version and upgrade it

Sometimes pip itself is old enough to cause weird behavior, especially around package resolution. Before you go too deep into troubleshooting, just upgrade it:

python -m pip install --upgrade pip

Also worth checking if virtualenv and pip are both present inside the venv after activation:

pip list

If you see basically nothing there, or the list looks like your global packages instead of a fresh environment, your activation definitely didn't work right.

One more thing — if you're on Windows and PowerShell is blocking the activation script, that's an execution policy issue. Run this once:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Then try activating again. Windows being Windows.

Look, the virtual environment system in Python is genuinely useful but the developer experience around it is rough around the edges. The activation model is confusing, the multiple-pip-on-one-machine situation is a mess, and the error messages when things go wrong don't really tell you what actually went wrong. Not Python's finest hour.

But once you internalize "always use python -m pip, always verify with which python", most of this stuff stops happening to you. Keep those two habits and you'll spend a lot less time fighting your environment and a lot more time actually writing code.