FULL PYTHON FIX · 6 MIN READ
ModuleNotFoundError After pip install: Check Your Python Environment
An install can succeed in one Python environment while your program runs in another. Prove which interpreter each command uses, then make installation and execution use the same one.
Quick answer: use the Python that runs your script
Print sys.executable from the same run that raises ModuleNotFoundError. In a local terminal, invoke that exact executable with -m pip install requests, then run the script with the same executable. Replace requests with your actual distribution name and check that its import name matches.
This diagnosis needs your local Python installation; the browser console cannot inspect your computer's virtual environments or install into them.
import sys
print(sys.executable)Video guide: ModuleNotFoundError After pip install: Check Your Python Environment
The preview is stored on this site. YouTube loads only when you press Play. Watch on YouTube
Jump to a chapter
Read the video transcript
Select a timestamp to watch that moment on YouTube.
- 00:00
You install a package, the installer says success, and your next Python run still says ModuleNotFoundError. That can feel contradictory, but the two messages may be coming from different Python environments. In this demonstration we will use a tiny module named p-l-l demo widget so the experiment is completely local and does not depend on an outside package server. We will put it in one environment and try to import it from another. Before watching the run, predict which interpreter can see the module. Then we will compare the executable paths and the pip paths, correct the command pair, and verify the import. The broader lesson is that pip installs into a particular interpreter's environment.
- 00:45
A plain pip command and a plain python command are only safe together after you have checked which executables your shell resolves. On machines with multiple Python versions, virtual environments, notebooks, or editor settings, those names may refer to different installations. The demonstration package is intentionally tiny: a single value in one module. That keeps the cause visible. Large real packages may have several import names and optional dependencies, but the interpreter boundary is exactly the same. Our first environment contains the demo module; our second one does not. Run the program using the second environment's Python.
- 01:28
The import line fails immediately with ModuleNotFoundError and names p-l-l demo widget. The package did not disappear. The interpreter that ran this file simply does not have that module on its import search path. The traceback names the import statement, which is useful: Python had not reached any application logic yet. This can happen after a successful pip install if you installed with one interpreter but launched your script with another. It also happens when an editor or notebook selects a different environment than your terminal. Resist the urge to repeat the same installation command without checking anything. That may install the same package into the same wrong place again.
- 02:12
We will ask both Python and pip where they are operating, and compare those answers directly. Keep the two environment labels visible while the commands run. A success message from pip in environment A is true, and the failure in environment B is also true. They refer to separate locations on disk. Start by printing sys dot executable in the process that actually raises the error. That is the full path to the Python interpreter running your code. In the terminal, call that same interpreter with dash m pip dash dash version. The output identifies the pip module and the Python version it belongs to.
- 02:52
Next ask the chosen interpreter whether it can import the module, or inspect its import search path. In our controlled run, one path includes the directory holding the demo module and the other path does not. This is an environment mismatch, not a spelling problem inside the module. On Windows, a virtual environment's interpreter is usually inside its Scripts directory. On macOS and Linux it is usually inside bin. The exact folder names are less important than matching the interpreter used for both actions. If the paths already match and the import still fails, check a different cause, including whether the name you pip installed differs from the name you import, or whether a local file shadows the package.
- 03:39
Compare the parent directory of sys dot executable with the pip location. If those paths name different environments, you have enough evidence to explain the failure. Avoid installing globally just to make the error disappear; that hides the mismatch. The reliable command shape is interpreter dash m pip install package, followed by that same interpreter running the script. In the demonstration, we select environment A explicitly for both commands. Pip reports the local demo package in environment A, and the import prints loaded from env A. We then run the same import with environment B to show that B remains isolated.
- 04:19
A virtual environment is supposed to work that way; isolation is its purpose. If you are using an editor, select the interpreter whose path you just checked, rather than assuming the editor follows your terminal automatically. If you are using a notebook, print sys dot executable in a notebook cell because the kernel may not be the same process as your shell. The key repair is not a magic pip flag. It is a consistent path that connects installation, execution, and any editor or notebook kernel you use. Using dash m asks the selected Python process to launch its own pip module. This removes ambiguity about a standalone pip executable on your command path.
- 05:03
It also makes a command in documentation easy to adapt by replacing one interpreter path. For a final check, print the module's file path after a successful import. It should point inside the environment or directory where you installed it. Then print sys dot executable once more in that same run, so you have evidence about both the code location and the interpreter. The controlled fixture in this production package also verifies the contrast: without the module path, import raises ModuleNotFoundError; with it, the value prints. For your own project, open a terminal in the project folder, activate the intended virtual environment if you use one, and run python dash m pip dash dash version and python dash c with an import and sys dot executable.
- 05:53
Write those paths down before trying another install. If a teammate cannot reproduce the setup, a requirements file or project configuration should describe the dependency. Try creating two small virtual environments yourself and install a tiny local package into only one. Explain why the other environment fails to import it. The Installing Python and Virtual Environments lesson on PythonLessonLab provides the foundation for that exercise. For verification, record three things: the interpreter path, the installed module file path, and the observed import result. If all three agree, the fix is reproducible.
- 06:35
Then try the other environment again to see that isolation still holds. The companion article uses requests, a public package, in its own install and import commands. Replace our local module name with requests in both commands; the interpreter matching test stays exactly the same.
The package is installed, but the import fails
The familiar symptom is a successful pip install followed by ModuleNotFoundError when you run the script. Repeating pip install blindly may keep installing into the same wrong place. Save the example below as app.py and run it with a fresh environment that does not contain requests. Confirm the exact name in the traceback and the command used to start the failing program.
A machine can have system Python, a virtual environment, a Python selected by an editor, and another Python inside a notebook. Each interpreter has its own import search locations. Installing into one does not automatically place the package in the others.
import requests
print(requests.__version__)ModuleNotFoundError: No module named 'requests'Identify the Python that actually runs your code
Run a short diagnostic with the same command or editor run button that produces the error. sys.executable prints the executable path for that Python process. Invoke that exact executable with -m pip --version to see its pip. The command python -m pip --version describes the terminal's python, which may differ from the interpreter selected by an editor.
The important comparison is between the interpreter used for the script and the one used for installation. If their paths point to different environments, you have found the cause. In an editor, also inspect its selected interpreter; a terminal activation does not guarantee the editor uses the same Python.
import sys
print('Running Python:', sys.executable)
import requestsRunning Python: ...\env-b\Scripts\python.exe
ModuleNotFoundError: No module named 'requests'python -c "import sys; print(sys.executable)"
python -m pip --versionCompare the terminal Python path with the failing script's path. If they differ, run the full path printed by the script with -m pip --version too.Install and run with one explicit interpreter
Create a project virtual environment and call its Python executable for both operations. Using python -m pip ties pip to the interpreter named before -m. This is more reliable than a bare pip command when several Python installations exist.
The commands below show the same idea on Windows and on macOS or Linux. Replace requests with the package you actually need. Select the same .venv interpreter in your editor or notebook. After installation, run the script through that executable rather than another global python command.
py -3 -m venv .venv
& .\.venv\Scripts\python.exe -m pip install requests
& .\.venv\Scripts\python.exe app.pyThe script imports requests using the same .venv that received the package.python3 -m venv .venv
.venv/bin/python -m pip install requests
.venv/bin/python app.pyThe script imports requests using the same .venv that received the package.Prove the import location, then check other causes
Run an import check through the chosen interpreter and print the module's file path. A real path inside .venv confirms that the import resolves there. For built-in modules, __file__ may be unavailable; this check is for an installed package such as requests.
If the interpreter paths already match, investigate the next likely causes instead of changing environments again. A distribution's install name may differ from its import name. A local file named requests.py can shadow the installed package. A notebook kernel can use a different interpreter from its terminal. Check the exact traceback and import name before reinstalling.
& .\.venv\Scripts\python.exe -c "import sys, requests; print(sys.executable); print(requests.__file__)"Both printed paths should belong to this project's .venv.- Compare sys.executable from the failing run with the interpreter used for python -m pip.
- Run the import through the same .venv Python that installed the package.
- If paths match, check import-name differences and local files that shadow packages.
Practice the fix
Create two fresh virtual environments named env-a and env-b. Install requests only in env-a, confirm import requests fails in env-b, then run it successfully with env-a's Python. Write down the two sys.executable paths before changing anything.
Need a hint?
Use the full path to each environment's python executable, then call that executable with -m pip and -c. The environment path matters more than the shell's activation indicator.
Python console
Ready to runThis browser console runs separate, in-browser Python. Use your local terminal for this guide’s project files, packages, and environment commands.
Does your code use input()? Add one value per line
Your output appears here.
Key takeaways
- ModuleNotFoundError after installation often means installation and execution used different Python interpreters.
- sys.executable identifies the running interpreter; python -m pip targets a specific interpreter.
- Choose one project virtual environment for both install and run commands.
- Matching paths do not prove the import name is correct; inspect shadowing and package naming separately.