Why Does Python Say a Package Is Installed When My Script Cannot Import It?

Why does Python say a package is installed when my script cannot import it?

Python says a package is installed when it exists in the package directories associated with the interpreter that ran the installation. Your script may be running another interpreter, where that package is absent. The fix is to line up three things: the environment where you installed the package, the Python command that runs your script, and the interpreter selected in your editor.

The Python Software Foundation explains that a venv environment has its own interpreter and package directories. By default, packages installed in the base Python are not available inside that environment. Isolation is useful: one project can use its own packages without changing another project’s setup. It also explains the classic mismatch: “installed” is not a universal status across every Python on your computer.

When you see ModuleNotFoundError, first check which environment is active and how the script is launched. If you installed a package before activating the project environment, it may have gone into the base Python instead. Activate the project environment, then install the package again through its interpreter. For example, run python -m pip install requests after activation, then run the script with python your_script.py from that same environment.

There is a reliable rule for avoiding this mismatch: attach pip to Python. The Python Packaging Authority (PyPA) recommends using a virtual environment for third-party packages and invoking pip through the intended interpreter, such as python -m pip. That command is more precise than typing pip alone, because it makes clear which Python owns the installation.

How do I create and activate a Python virtual environment?

Create a virtual environment from your project folder with python -m venv .venv, then activate it using the script for your operating system. The Python documentation describes venv as a standard-library module for making isolated environments; activation changes the command-line session so its Python and pip resolve to that environment.

Run the creation command from the folder where you want the project environment stored. The name .venv is a practical convention, but it is simply the directory name in this command. If your computer uses a version-specific Python command, use that command consistently to create and later run the environment.

These commands reflect the platform-specific locations documented for activation scripts: Scripts on Windows and bin on Unix-like systems. Once activated, install a package with python -m pip install package-name and run your program with python in the same terminal. If the terminal is right but an editor still cannot import a package, select the project’s .venv interpreter in the editor.

To leave the environment, run deactivate. The environment is disposable: the Python documentation says it should be simple to delete and recreate rather than moved to another location. Treat it as a project tool, not as the only copy of your dependency plan. Keep the requirements file with the project so the environment can be rebuilt.

How can I tell which Python interpreter pip is using?

Ask pip through the interpreter you want to check: use python -m pip --version in an activated environment, or use PyPA’s platform-specific check, python3 -m pip --version on Unix or macOS and py -m pip --version on Windows. This links the pip check to an explicit Python command instead of relying on a potentially different standalone pip executable.

Use the same pattern for installation. On Unix or macOS, PyPA documents python3 -m pip install requests; on Windows, it documents py -m pip install requests. When an environment is active, python -m pip is a straightforward way to install into the Python selected by that environment. Check the version command after activation if you want to confirm what pip is attached to.

For project sharing, record the packages and versions the project needs in requirements.txt. A requirements file can specify exact versions, such as requests==2.18.4. The exact version in that example is illustrative of the documented pin format; choose versions appropriate to your project rather than copying it automatically.

PyPA describes pip freeze as useful for producing a list of installed package versions and creating a requirements file that can recreate those versions. After saving the file, another setup—or your own clean environment—can install the listed dependencies with python -m pip install -r requirements.txt. That turns “it works on my machine” into a repeatable setup step: share the file, create the environment, and install from the file.

If the package still cannot be imported, trace the chain in order: activate the intended environment, check pip with that environment’s Python, install from the requirements file, and launch the script using the same Python. This short sequence separates an installation problem from an interpreter-selection problem without guessing which copy of pip ran.