Why do I get ModuleNotFoundError for ‘requests’ even after installing it with pip?

## 

Python scripts failing with `ModuleNotFoundError: No module named 'requests'` despite successful installation via `pip`. The core issue is **environment mismatch**: the Python interpreter used at runtime differs from the one associated with the `pip` that installed the package. Common triggers include multiple Python installations and IDE misconfiguration.



## Root 

- **Interpreter-`pip` misalignment**: Commands run in the VS Code terminal versus the VS Code-selected interpreter resolve to different Python environments.

- **Virtual environment activation failure**: The correct virtual environment isn't activated in the terminal or selected in VS Code.

- **PATH ordering**: The system prioritizes a system-wide Python installation over a user-specific or virtual environment installation when executing `python`.



## Why This Happens in Real 

- Multiple Python versions installed system-wide (e.g., pre-installed OS Python, manually installed Python, Homebrew/Pyenv versions).

- IDE's default Python interpreter differs from the user's terminal environment.

- Virtual environments are project-specific, making PATH configurations brittle across tools.

- Legacy scripts/modules may enforce interpreter constraints via shebangs (`#!/usr/bin/python`).



## Real-World 

- **Project delays**: Breaks script execution flow during critical development or deployment.

- **False debugging cycles**: Engineers attribute failure to installation problems instead of environment mismatches.

- **Reproducibility issues**: Scripts work inconsistently across team members' machines.

- **Security risks**: Accidental execution under unpatched/legacy Python interpreters in wrong environments.



## Example or Code (if applicable)

### Misaligned Environments in Terminal vs. 

Run these commands in VS Code terminal:

which python # Output: /usr/bin/python3 (system Python)

pip install requests # Installs to /usr/local/lib/python3.9/site-packages*

Meanwhile, VS Code uses a virtual environment interpreter for script execution:

Selected Interpreter: ~/project/venv/bin/

Script imports fail because `requests` isn't in `venv`.



### Symptom in Python

import

print(sys.executable) # Output: /usr/local/bin/

print(sys.path) # Shows incorrect site-packages

## How Senior Engineers Fix 

1. **Force terminal/env alignment**:

source venv/bin/activate # Activate virtual environment

2. **Match IDE interpreter to terminal**: Select interpreter **via VS Code Palette** (`Ctrl+Shift+P` → Python: Select Interpreter) or `.vscode/settings.json`:

{

“python.defaultInterpreterPath”: “${workspaceFolder}/venv/bin/python”

}

3. **Validate interpreter-pip consistency**:

Check interpreter path and associated

which

python -m pip list | grep

4. **Install with `python -m pip`**: Always use the module-mode to bind install to current `python`:

python -m pip install

5. **Enable environment consistency tools**: Use `pipenv`/`poetry` for dependency management and environment locking.



## Why Juniors Miss 

- **Assumption that `pip install` is global**: Unaware that `pip` is tied to a specific interpreter/env.

- **Tooling abstraction**: Reliance on VS Code's automation without understanding environment selection mechanics.

- **PATH complexity**: Difficulty tracing `PATH` precedence when shadowing occurs from prior Python installs.

- **"It worked yesterday" bias**: Failure to recognize environmental drift in virtual environments or IDE updates.

- **Cultural gaps**: Prioritizing syntax-focused learning over environment/python-path fundamentals.