Python "python" Runs the Wrong Interpreter vs "python3" in CI

python and python3 can point at different interpreters on the same runner. A bare python may be an old system Python (or none), while python3 is the one you configured - so installs and imports silently target the wrong environment.

What this error means

A step that calls python installs or runs under a different version than a step that calls python3 (or the active venv). Packages installed with one are "missing" under the other, and python --version disagrees with python3 --version.

CI log

$ python --version
Python 2.7.18
$ python3 --version
Python 3.12.3
$ python -m pip install requests   # lands in the 2.7 site-packages
$ python3 -c "import requests"      # ModuleNotFoundError

Common causes

Two interpreters on PATH

The image ships both a legacy python (often 2.x or an older 3.x) and a python3. Whichever resolves first for python is not the one you set up.

A venv or pyenv shim not first on PATH

The active venv’s python is not first on PATH, so a bare python falls through to a system or pyenv-shim interpreter instead.

How to fix it

Pick one interpreter and reference it consistently

Use python3 (or the venv’s python) everywhere, and confirm what it resolves to.

Terminal

which python python3
python3 --version
python3 -m pip install -r requirements.txt
python3 -m pytest

Put the intended interpreter first on PATH

Activate the venv or write its bin to the job PATH so a bare python is the right one.

.github/workflows/ci.yml

- run: |
    python3 -m venv .venv
    echo "$PWD/.venv/bin" >> "$GITHUB_PATH"
- run: python --version   # now the venv interpreter

How to prevent it

Standardize on python3 -m ... (or an activated venv) across all steps.
Assert python --version early so a mismatch fails fast.
Install python-is-python3 only when you control what python should mean.