Jitsumi
Back to the blog

Python module not found after pip install? Check the interpreter

Pip says the package is installed, but Python cannot import it? Find the interpreter running your code, check its environment and fix the mismatch.

Two separate open cases, with a yellow component in the left case and an empty slot in the right.

You install a Python library, pip reports success, and your script immediately stops with ModuleNotFoundError: No module named 'requests'. Repeating the installation produces another reassuring message. The script still fails.

One explanation is that the installation and the script are using different Python environments. Start by finding the Python executable inside the failing run, then ask that exact Python about the package. That gives you a useful next step before you reinstall anything.

This guide focuses on local Python 3 projects on Windows, with PowerShell commands and separate checks for VS Code and notebooks. Requests is the example library; use your own project's documented package name and version requirements. If the project already uses Conda, uv or another environment manager, keep its installation workflow and apply the interpreter checks to the environment it manages.

How an installation can succeed while an import fails

An installed package belongs to an environment. It does not become available to every Python installation on the computer.

For example, imagine two ordinary virtual environments created with Python's venv module. You install Requests in environment A, then run a script with environment B. A can import the package; B has no copy to import. Both environments can even report the same Python version. Python's virtual environment documentation explains this separation of installed packages.

The missing piece is which environment each command actually uses.

Python A finds requests in environment A. Python B cannot import it because requests is absent from environment B.

*Two separate default virtual environments can have different installed packages, even when they use the same Python version.*

The same distinction matters when a terminal and an editor choose different interpreters. A successful installation in the terminal does not establish what the editor will run.

1. Identify the Python that runs the failing code

Add these lines before the failing import, then launch the script in the same way that produced the error:

import sys
print(sys.executable)
print(sys.version)

If the failure happens in a notebook, run those lines in a notebook cell. If it happens when you press Run or Debug in an editor, use that same action. Opening an unrelated terminal and checking its Python can answer a different question.

`sys.executable` reports the running interpreter's executable path in a normal desktop Python installation. An illustrative Windows result is:

C:\work\demo\.venv\Scripts\python.exe

Keep the path that your own run prints. The version is useful context, but the executable path distinguishes environments that use the same release.

Run the next commands in PowerShell, outside Python's >>> prompt. Set a variable to your actual executable path; the path below is an example to replace:

$projectPython = 'C:\work\demo\.venv\Scripts\python.exe'
& $projectPython -m pip --version
& $projectPython -m pip show requests

PowerShell's call operator, `&` , runs the executable stored in the variable. The arguments remain outside the quoted path, so paths containing spaces work too.

The important part is -m pip: it runs pip through the specified interpreter. The pip user guide documents this relationship. Writing python -m pip is useful only when python is the interpreter you intend to use; the explicit path removes that ambiguity.

2. Read the result before installing again

`pip show` reports information about an installed distribution, including its name, version and location.

What you find

What it tells you

Next step

The package is not found

This pip invocation does not see an installed distribution with that name.

Confirm the package name and decide whether this is the intended project environment.

The package is listed

Installation metadata exists in a location visible to this pip invocation.

Try the import with the same interpreter; a listing alone does not prove the import works.

Python reports No module named pip

That interpreter cannot import pip.

Check how the environment was created and follow its installation or repair instructions.

The interpreter path and package location are not supposed to be identical. For the example above, python.exe is under .venv\Scripts, while an ordinary installed package is under .venv\Lib\site-packages. The shared .venv directory is the useful connection.

If your original command was bare pip install requests, also run pip --version in that same terminal. Compare it with the explicit-path command above. A different pip location can explain why one installation appeared successful while the script could not use it.

Now choose the environment deliberately:

  • If the editor selected the wrong environment, switch it to the project's existing environment.
  • If the script uses the correct environment but the required package is missing, install it there using the project's documented dependencies.
  • If this is a new project without an environment, use the short setup later in this guide.

For a simple project that needs Requests and has no separate version constraint, the explicit installation is:

& $projectPython -m pip install requests

This uses the package name from Requests' own installation instructions . In an existing project, follow its requirements file or environment manager instead of substituting an unconstrained installation.

Then check the import:

& $projectPython -c "import requests; print(requests.__file__)"

A successful import prints the file Python loaded. For an ordinary installation in the example environment, expect that path to be inside .venv\Lib\site-packages\requests. A path to your own requests.py file is a different clue, covered below.

Finally, rerun the original script using its original Run, Debug or terminal command. The standalone check confirms an import in that process; the original launch confirms whether you fixed the workflow that was failing.

3. Match VS Code and notebook settings to the environment

VS Code scripts

With Microsoft's Python extension installed, open the Command Palette with Ctrl+Shift+P, run Python: Select Interpreter, and select the interpreter belonging to your project. Compare its path with the one you checked above.

VS Code's environment documentation says the selected environment is used for running code, debugging and language features. A debug configuration can override it through the python property in launch.json.

If Run works but Debug fails, inspect that override. Rerun the sys.executable check through the failing action after changing the selection; the printed path is the confirmation that matters. A separate task or third-party run extension may have its own launch command, so check that command if the path still differs.

Jupyter notebooks

A notebook's kernel is the process that executes its cells. Check sys.executable inside the notebook itself, even if a Python script in the same folder works. If the kernel runs remotely, in WSL or in a container, make installation changes in that environment; its executable path cannot be used as a local Windows executable.

In VS Code, use Select Kernel at the upper right of the notebook, or Notebook: Select Notebook Kernel in the Command Palette. This is a separate choice from the script interpreter, as shown in Microsoft's Jupyter kernel guidance .

For an IPython-backed Python notebook whose current environment should receive Requests, these cell commands target that kernel:

%pip show requests
%pip install requests

Run the installation only if it fits the project's dependency instructions. IPython documents `%pip` as running pip within the current kernel . It is an IPython command, so it does not belong in a normal .py file or a PowerShell window.

Restart the kernel if the installer requests it, then rerun the relevant cells. If a library was already imported before you changed its installation, a fresh kernel also avoids checking a previously loaded copy.

For a new project, make the environment explicit

If you are starting a plain Python project, use a new project folder with no existing .venv directory. Check the Python you intend to use as its base:

python -c "import sys; print(sys.executable); print(sys.version)"

If that is the intended installation, create the environment:

python -m venv .venv

The environment uses the Python version that ran the creation command, as explained in the Python virtual environment tutorial . If python is not the intended installation, use its confirmed executable path with & instead. Do not assume switching from python to py selects the same runtime on every Windows setup; Python's Windows guide covers its launcher and install-manager behaviour.

From that project folder, use the environment's executable for both installation and execution:

.\.venv\Scripts\python.exe -m pip install requests
.\.venv\Scripts\python.exe -c "import requests; print(requests.__file__)"

To run a script named app.py that you have saved in the project folder:

.\.venv\Scripts\python.exe .\app.py

Keep your source files in the project folder, outside .venv. If you use VS Code, select this same .venv\Scripts\python.exe as the interpreter.

Activation is optional. Python explicitly supports calling the environment's interpreter directly . This route does not require running Activate.ps1 or changing PowerShell's execution policy. Activation is a convenience for command selection; it is not a required step before the environment can run Python.

If the interpreter matches, check the import itself

Once the intended interpreter sees the expected package, repeated installations stop being a useful first response. Read the full traceback, especially its final missing name and the files leading to it.

The installation name and import name can differ

The name you give pip is a distribution name. The name in an import statement is an import name. They often match, but matching is a convention rather than a requirement.

For example, the Python Packaging User Guide explains that the distribution Pillow provides the import package PIL. Code uses from PIL import Image, while a package check uses pip show Pillow. See its distribution-versus-import explanation .

Check the library's own documentation before installing an unfamiliar name copied from an error. The Packaging User Guide warns that a matching name on a package index can belong to an unrelated project.

A local file can hide the installed library

Check whether your project contains a file such as requests.py, or a package directory called requests. Python normally places the script's directory early in its module search path , so local code can be found before the installed library.

If your own script accidentally has the library's name, rename it to something specific, such as fetch_weather.py, and retry in a fresh process. Do not rename the installed package. The path from requests.__file__, when the import succeeds, helps distinguish the two.

The missing name may belong to a dependency

Your script might import one library, which then imports something else that is missing. Python defines `ModuleNotFoundError` as a failure to locate a module; it does not identify the installation mistake that caused it.

Read the final missing name alongside the traceback. For the same selected interpreter, this check can identify missing or incompatible declared dependencies. If you changed environments or opened a new PowerShell session, rerun sys.executable through the failing launch and set $projectPython to that path first:

& $projectPython -m pip check

`pip check` checks dependency compatibility. It does not test every import, optional feature or native library. If the error is instead ImportError: DLL load failed, or a requested function no longer exists, follow that package's platform and version guidance. Those symptoms need a diagnosis beyond choosing the installation environment.

Finish by checking the original launch

You have resolved the environment mismatch when the original script or notebook runs with the intended interpreter and imports the expected package from the expected location.

Keep the temporary sys.executable check until that succeeds. Then remove the diagnostic lines and carry on with the project. The useful habit is to choose the environment once and use it consistently for installing packages, running scripts and configuring the editor.

Sources and further reading

Documentation checked on 26 October 2026. The Windows commands follow official documentation; example paths are illustrative.