Photo by Nong on Unsplash

It was a Tuesday afternoon and I had literally one task: run a script that scraped some data and dumped it into a CSV. Twenty lines of code. Five minutes, tops. Except Python had other plans. I ran the script, and immediately got slapped with an ImportError: No module named 'requests' — even though I had definitely, absolutely, one hundred percent installed requests like ten minutes earlier.

Sound familiar? This is one of those errors that makes you feel like you're losing your mind. You know you installed the package. You watched pip do its thing. And yet Python is standing there telling you it has no idea what you're talking about. The reason this happens is actually pretty specific, and once you see it, you'll never be confused by it again. But finding that reason the first time? That's the painful part.

What the Error Actually Looks Like

Traceback (most recent call last):
  File "myscript.py", line 3, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'

Sometimes it's ImportError, sometimes it's ModuleNotFoundError — which is technically a subclass of ImportError, so they're basically the same problem. You might also see variants like:

ImportError: cannot import name 'json' from 'simplejson'
ImportError: No module named 'cv2'
error: externally-managed-environment

That last one is newer and it's its own special headache. We'll get to it.

Photo by Taiki Ishikawa on Unsplash

Why This Happens: You Have Multiple Pythons

Here's the thing that catches almost everyone. Your machine almost certainly has more than one Python installation. There's the system Python, maybe a Homebrew Python if you're on Mac, possibly a conda environment, and whatever you installed from python.org. When you run pip install requests, you might be installing into Python 3.10's site-packages. But when you run python myscript.py, you might actually be running Python 3.9. Different Python, different site-packages folder, no requests. Mystery solved — kind of infuriatingly.

You can verify this immediately:

which python
which python3
which pip
which pip3
python --version
pip --version

Look at those paths. If pip points to one Python installation and python points to another, that's your problem right there. I've seen this a hundred times and it always looks the same in the output.

Why This Happens: You're Not in Your Virtual Environment

Virtual environments exist specifically to avoid this mess. But they only help if you actually activate them before running your code. Obvious, right? Except I've personally forgotten to activate a venv embarrassingly often.

Check if you're in one:

echo $VIRTUAL_ENV

If that returns nothing, you're not in any venv. If you're supposed to be, you forgot to activate it. This is also why your terminal prompt usually shows the venv name in parentheses — it's trying to remind you. I stopped noticing it for a while and paid the price.

Fix 1: Make Sure pip and Python Are the Same

The safest way to install packages is to call pip through the specific Python interpreter you're actually using. Stop using bare pip for this. Use:

python -m pip install requests

Or even more explicitly:

python3.11 -m pip install requests

The -m pip flag forces Python to use its own pip, not whatever pip command your shell finds first. This single change fixes the mismatched-interpreter problem almost every time. Honestly, I wish I'd known about this years earlier.

Fix 2: Set Up a Virtual Environment Properly

If you're working on any project that's more than a throwaway script, just use a venv. Always. No exceptions. Here's the whole thing:

# Create the venv
python3 -m venv venv

# Activate it (Mac/Linux)
source venv/bin/activate

# Activate it (Windows)
venv\Scripts\activate

# Now install your package — it goes into the right place
pip install requests

# Run your script
python myscript.py

When you're inside the venv, python and pip both point to the same place. No ambiguity. And your project dependencies don't pollute your global Python installation. The downside? You have to remember to activate it every time you open a new terminal. That part is mildly annoying. But it's worth it.

Fix 3: The externally-managed-environment Error (Python 3.11+)

This one is newer and honestly threw me off the first time I saw it. On newer systems — especially Debian, Ubuntu 23+, and recent macOS setups — running pip install globally gives you this:

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, either use a Linux distribution
    package manager or install in a virtual environment.

The system is actively blocking you from installing packages globally. It's doing this to protect the system Python that the OS itself depends on. Annoying? Yes. Reasonable? Also yes, actually. The fix is just — use a venv, like Fix 2 above.

But if you absolutely need to override it for some reason (a quick test, a CI script, something one-off), you can do:

pip install requests --break-system-packages

The flag name alone should tell you this isn't for everyday use. Don't make it a habit. It's there for edge cases, not as a default workaround.

Fallback: Check Where Python Is Actually Looking

When nothing makes sense, run this. It'll show you exactly which directories Python searches when you do an import:

python -c "import sys; print('\n'.join(sys.path))"

Look at that list. Is the site-packages folder you expected in there? If not, you've found your problem. You can also check where a specific package is installed:

python -c "import requests; print(requests.__file__)"

If that errors, it's not importable from your current Python. If it succeeds, it prints the exact file path — which tells you which Python installation actually has it.

And look, if you're using an IDE like VS Code, make sure the Python interpreter it's using matches your venv. There's a little interpreter selector in the bottom right corner. I've watched people debug for 40 minutes before realizing VS Code was pointed at the wrong Python the whole time.

Once you wrap your head around the fact that "Python" on your machine isn't one thing but potentially several different things with different package sets, these errors stop being mysterious. They're annoying, but at least they're predictable. Venvs, python -m pip, and checking your interpreter path — that's really the whole toolkit. You'll be good.