pip Not Working After Upgrading to Python 3.14

Upgrading Python is the most reliable way to break pip, because pip is not one program: every Python installation has its own copy, and pip on the command line is whichever one is found first. After installing 3.14 you may have no pip command, a pip that still installs into 3.13, or a pip that works but cannot install anything because packages have not caught up with the new version. Each has a different fix, and one habit avoids all three.

The habit that avoids most of this#

python -m pip install requests
py -3.14 -m pip install requests       # Windows: pick the version explicitly
python3.14 -m pip install requests     # macOS/Linux

Running pip as a module of a specific interpreter guarantees the package goes into that interpreter. The bare pip command depends on the PATH, and the PATH is exactly what an upgrade disturbs. Adopt -m pip and the wrong-Python class of problem disappears.

Cause 1: pip is not recognised#

The pip executable lives in a Scripts folder (Windows) or bin folder (macOS/Linux) beside the interpreter. If the 3.14 installer did not add that folder to the PATH, pip is not found even though python is.

python -m pip --version        # works? then pip exists and only the command is missing

If that works, either use -m pip permanently or add the Scripts folder to the PATH. On Windows the folder is next to python.exe; find it with:

python -c "import sys, os; print(os.path.join(os.path.dirname(sys.executable), 'Scripts'))"

If python -m pip says there is no module named pip, pip was not installed with the interpreter. Bootstrap it:

python -m ensurepip --upgrade
python -m pip --version

Cause 2: pip installs into the old Python#

pip --version
# pip 24.x from /usr/lib/python3.13/site-packages/pip (python 3.13)
python --version
# Python 3.14.0

Two different interpreters. The pip on the PATH belongs to 3.13; the python on the PATH is 3.14. Packages install fine and then cannot be imported, because they went into the wrong place.

The fix is python -m pip. If you want the bare command to match, reorder the PATH so 3.14’s Scripts or bin folder comes before 3.13’s, or uninstall 3.13 if nothing needs it.

where.exe pip python           # Windows: shows every match in PATH order
which -a pip python3           # macOS/Linux

Cause 3: pip works but packages will not install#

ERROR: Could not find a version that satisfies the requirement numpy
ERROR: Failed building wheel for pillow

A new Python version needs packages to publish compiled builds, called wheels, for it. In the weeks after a release, many have not. pip then tries to compile from source, which needs a C compiler and often fails.

python -m pip install --upgrade pip
python -m pip install --only-binary :all: numpy     # refuse to build; fail fast if no wheel

If the second command fails, there is no 3.14 wheel yet for that package. Your options: wait, install the build tools and compile, or use 3.13 for that project until the ecosystem catches up. This is the strongest argument for not moving production work to a brand-new release immediately.

Old pip is also a cause: a pip from before the release does not understand the new version’s wheel tags. Upgrading pip itself is the first thing to try.

Cause 4: an old virtual environment#

A virtual environment is tied to the interpreter that created it. After upgrading, a .venv made with 3.13 either keeps using 3.13 (fine, if 3.13 still exists) or breaks (if it was removed). Environments do not upgrade; they get recreated:

rm -rf .venv
python3.14 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

Keep a requirements.txt or pyproject.toml so this is a one-minute job. If you use uv, uv venv --python 3.14 and uv sync do the same in seconds.

Externally managed environment#

On Linux and with Homebrew, installing into the system Python is refused with an “externally-managed-environment” message. That is deliberate. Use a virtual environment, as above, rather than the override flag.

Where to go next#

• ‘python’ is not recognized — the same PATH problem for the interpreter.
• bdist_wheel did not run successfully — when compiling from source fails.
• uv vs pip — the tool that sidesteps most of this.