pip installed the package but Python cannot import it: compare interpreters
By ON Lab · Sources checked November 8, 2026
An installed distribution is available to the interpreter where it was installed, not automatically to every Python on the machine. Print sys.executable in the process that fails, then use that exact interpreter for -m pip show and any intended installation. In VS Code, compare that path with the selected Python environment instead of repeating a global pip command.
The reader question behind this guide reported that a module worked from the command line after installation but remained missing in VS Code. We verified the environment distinction with two disposable virtual environments and our own tiny local wheel. We did not install the reader's package, reproduce their Windows setup or change any IDE settings.
Start in the process that actually fails
Run this inspection in the same script, console or run configuration that cannot import the module:
import sys
print(sys.executable)
print(sys.version)
print(sys.prefix)
Keep the output with the exact error. A terminal prompt showing an environment name is a clue, but the interpreter path from the failing process is stronger evidence. A successful command in another terminal does not establish which environment an editor or debugger uses.
Read the complete missing-module name in the traceback. A missing dependency inside an otherwise installed package is different from Python being unable to locate the top-level module you intended to import. Do not install a package merely by copying an unfamiliar name from an error without checking its documentation.
Ask that interpreter about the installation
Replace the path and distribution name with the values you have verified. These examples use a POSIX-style shell:
"/path/to/intended/python" -m pip --version
"/path/to/intended/python" -m pip show YOUR_DISTRIBUTION
The pip user guide documents invoking pip through Python with -m pip. Doing so binds the package-management operation to that interpreter. Compare pip's displayed path and the distribution's Location with the environment you intended to use.
If pip show cannot find the distribution there, distinguish that from the result of a different bare pip show command. If the interpreter has no pip module, record that as a separate setup issue. It is not proof that the requested package is globally absent.
The distribution installed by pip and its import name can differ. Use the package's own installation and import examples. Our fixture uses the distribution desk-import-demo and the module desk_import_demo; those names are synthetic and are not a recommendation to install an unfamiliar public package.
What the two-environment test showed
We created env-a and env-b using the same existing Python installation. Each was a fresh virtual environment. We installed our local wheel into env-a with that environment's Python and -m pip install --no-index, without contacting a public index.
| Check | Observed result | Meaning in the fixture |
|---|---|---|
| env-a imports the test module | Success; marker and module file path printed | The local wheel was usable in env-a |
| env-b imports the same name | ModuleNotFoundError | Installing in env-a did not install in env-b |
| env-b runs pip show for the distribution | Package not found | The package inventory matched the failing environment |
| env-a runs pip show | Distribution metadata and env-a location printed | The successful installation belonged to env-a |
| Install the wheel through env-b's Python, then import again | Success; module file path inside env-b printed | The change affected the intended second environment |
We checked the import output and file locations after installation, not just pip's success message. This demonstrates isolation; it does not prove that every import error is an interpreter mismatch.
Choose the intended environment instead of changing all of them
You have two different possible intentions: run the program with the environment that already contains its dependencies, or install the required dependency into the environment the program should use. Decide which is correct for the project before making either change.
VS Code documents Python: Select Interpreter for choosing the Python environment. Compare the selected environment with the path printed by the failing run. After an environment change, rerun the same inspection from the same execution route and confirm the actual path. Do not infer that every existing terminal, notebook kernel or custom run configuration has changed solely because a selector changed.
If an installation is appropriate, use the project's documented dependency workflow and the intended interpreter. A controlled installation would take the form "/path/to/intended/python" -m pip install YOUR_DISTRIBUTION, but do not bypass a project lockfile or approved environment policy just to make a one-off import succeed. No global administrator installation is needed to demonstrate the mismatch.
If the interpreter and installation already agree
Stop repeating the same installation. Record the exact import statement, full traceback, distribution metadata, interpreter path and module name from the package's documentation. A package-specific failure, missing dependency or import-path issue may require another investigation.
Use a small non-confidential reproduction when asking for support. Avoid publishing private project paths or credentials from verbose logs. This guide does not test binary compatibility for the reader's original package and does not promise that interpreter selection repairs a native-library loading failure.
If the issue is specifically that uv run changes the project's Python version, use the separate uv interpreter-selection guide. That concerns how the project selects an environment, while this guide checks where installation and import actually occur.