Why can `python -m pip install` and a bare `pip install` target different interpreters?

## Two commands, two different resolutions The two spellings look interchangeable, but the shell resolves them by different routes, and that difference is the single most common cause of the “but I installed it!” bug. When you type `pip install X`, the shell walks `PATH` directory by directory looking for an executable file literally named `pip` and runs the first one it finds. That file is a *console script*: a tiny generated launcher whose first line is a shebang naming an absolute interpreter path, for example `#!/usr/local/bin/python3.14` or `#!/srv/annot/.venv/bin/python3`. The script itself imports pip and calls its entry point. So the interpreter that ends up receiving your install is whichever one that shebang names — chosen at the moment pip was installed, not at the moment you ran it. When you type `python -m pip install X`, the shell resolves only the word `python`. That interpreter starts, and `-m` tells it to locate the module (here, the package `pip`) on its own `sys.path` and run it as `__main__`. The pip that runs is therefore by construction the pip installed into that interpreter's environment, and anything it installs goes into that same environment's `site-packages`. ## Why several interpreters exist in the first place A developer machine or a build image typically carries more than one: an interpreter the operating system ships and uses for its own tooling, one or more installed by a version manager or from python.org, and one per project environment. Each has its own `site-packages` and, if pip is installed there, its own `pip` executable. Two of them may both put a file named `pip` on `PATH`; the earlier directory wins, silently. Names like `pip3` help only a little — `pip3` says “some Python 3”, never *which* Python 3. ## Diagnosing it in under a minute The ground truth for “which interpreter am I in?” is `sys.executable`, the absolute path of the running interpreter binary. `sys.prefix` gives the root of its environment, and comparing `sys.prefix` with `sys.base_prefix` tells you whether it is a virtual environment or the interpreter that created one. On the tooling side, `pip --version` prints pip's own file location *and* the interpreter it serves — that one line usually settles the argument. `shutil.which("pip")` from inside the failing interpreter shows you which `pip` the shell would have picked, and reading that file's first line shows the shebang it will obey. The rule of thumb that falls out: **name the interpreter, not the tool.** Instead of `pip install X`, run `/path/to/python -m pip install X`, or `.venv/bin/python -m pip install X`. The same discipline applies to any Python-implemented CLI you might want to drive deterministically. ## The same problem from inside a program A Python process that shells out to “Python” has exactly this ambiguity, and the fix is the same idea: pass `sys.executable` as the command rather than the string `python`. A child launched as `[sys.executable, "-m", "something"]` is guaranteed to be the same interpreter, with the same environment and the same installed packages, as the parent. Passing `"python"` instead delegates the choice back to `PATH` — which is how a worker process ends up importing a different version of a library than the parent that spawned it. ## When `-m` still is not enough Using `-m` removes the interpreter ambiguity but not every cause of a failed import. Three survive it. First, the *distribution* name you install and the *module* name you import need not match — many projects publish under a name that differs from the importable package, so `import` fails while the install was perfectly correct; `importlib.metadata.version("<distribution-name>")` confirms the distribution really is present for this interpreter. Second, a per-user install directory can be involved: pip may write to it while the interpreter is configured to ignore it, so the files exist but are not on `sys.path`. Third, a local file or directory in the working directory can shadow the installed package, because the script's own directory is searched first. So the diagnosis order is: confirm the interpreter with `sys.executable`, confirm the distribution with `importlib.metadata`, then confirm nothing local is shadowing the import.