Post History

Problems like this occur, fundamentally, because [there is more than one Python installation on the system](https://software.codidact.com/posts/291616), *and* the system is configured in a way that `pip` installs for a different Python than the one that `python` runs.

This problem can be addressed by **either**:

* [using a virtual environment](https://software.codidact.com/posts/291740)
* [running Pip indirectly through Python](https://software.codidact.com/posts/291675) - `python -m pip` or `py -m pip`.

<details><summary>In detail, the problem occurs because:</summary>

1. Pip is itself implemented in Python, and even when the command you use is `pip`, a Python interpreter needs to run. (On Mac and Linux, `pip` is a Python script [that has a shebang line and executable bit set](https://software.codidact.com/posts/291736); on Windows, it's a very small program that spawns a Python process to run the Pip code - sort of like a [bundled-interpreter application](https://software.codidact.com/posts/291738), but without actually bundling the interpreter.)

1. Pip generally installs packages according to the path where that Python interpreter was found. This means you don't have to tell it every time, and is convenient for some systems that are carefully configured to make it work properly. (Activating a virtual environment could be considered as this kind of configuration.)

1. There can only be one file (executable or not) with the same name in the same folder; and when you run a command at the command line, it can only find one of those programs. So `pip` means whichever program (if any) is found *first* by looking at entries in the `PATH` environment variable, one by one - once Pip is found, the search stops. Similarly for `python` (or `python3` etc.)

1. What happens next depends on the exact system configuration.

    * When you install Python on Windows, each Python minor version gets a separate sub-folder within `Program Files` or a similarly named folder. (Long ago, Python would put its install folders directly under `C:\`.) By default, these folders are **not** added to `PATH`, in part because over time that could make the `PATH` really long (long enough to bump into system-imposed limits). Instead, you're expected to use [the Python launcher for Windows](https://docs.python.org/3/using/windows.html#python-launcher-for-windows), called `py` (which is common to all versions, and sites directly in `C:\Windows`). But *there is no equivalent "launcher" for Pip* (of course, `py -m pip` solves the problem anyway).

        If `pip` is runnable as a command, it's because *some* Python folder was added to `PATH` - and it might not be the one you want. *Normally, if* `pip` and `python` both works as commands, then they would find the same installation folder. But this wouldn't work if, for example, Pip were not installed for first Python listed: then `python` would find that Python, but `pip` wouldn't (and could find a different Python).

    * When you install Python on Linux, typically it puts versioned `pip` and `python` executables (for example, they might be named `pip3.12` and `python3.12`) side by side right in `/usr/bin`, and sets up symlinks for `python`, `python3` etc. But those symlinks can only mean one version at a time, and it's possible for them to get out of sync. So `pip` and `python` can use different Python installations even though they're in the same folder.

        Also, keep in mind that it's common for a Python installation that comes with Linux, to have several features disabled - especially Pip - typically for security reasons. (It would be bad if, for example, you could easily use Pip to upgrade a third-party library that came pre-installed in your system Python, which a critical system script depends on, and the update broke that script. Even worse, PyPI can host malware - anyone can offer a package, and not everyone is reading the source code for every version of every upload. **Never use `sudo` to run Pip.**)
</details>

<section class="notice is-success">

**There is nothing wrong with having multiple Python installations on your system**.

Many developers will find it *necessary* to have multiple versions installed for their day-to-day work. Beyond that, virtual environments (which are essentially separate installations, for these purposes) are very useful for organizing projects.

However, in order to use third-party libraries successfully, you need to understand these basic principles.
</section>