Description

Python 3.12 on the ubuntu-24.04 image (which is also slowly becoming ubuntu-latest) is using an "Externally Managed" instance of Python - either it was installed via a package manager (apt?) or it is packaged with the OS. This also uses PIP 24, which (starting with PIP 23) enforces EXTERNALLY-MANAGED flagged python installs.

If your workflow includes anything that tries to do a pip install to set up python dependencies, it will fail with an error similar to:

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
    
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
    
    See /usr/share/doc/python3.12/README.venv for more information.

We found this by accident because our workflows target ubuntu-latest which is slowly being changed to target ubuntu-24.04 instead of ubuntu-22.04. We confirmed that adding a setup-python step to our workflow (which sets up 3.12.3) fixes the problem because it'll install a stand-alone interpreter and update the system path to use that interpreter, however there is no documentation anywhere saying that is now a requirement. Hence this issue :)

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

  Image: ubuntu-24.04
  Version: 20241006.1.0

HOWEVER, we were targeting ubuntu-latest and discovered on subsequent runs that ubuntu-latest targeted ubuntu-22.04 which made this intermittent for us. When we hard-targeted ubuntu-24.04 we consistently reproduced this.

I can't provide a build link due to client confidentiality purposes, however this is pretty easy to test.

Is it regression?

Yes (since the behavior of ubuntu-latest changed and broke a workflow)

Expected behavior

PIP should continue to work, or GitHub needs to formally publish the breaking change along with remediation steps (which is to use the setup-python action). Ideally, the version of Python that comes pre-installed on the runner image is not externally managed.

Actual behavior

See the error in the description... :)

Also - the inconsistency with using ubuntu-latest being either ubuntu-22.04 and ubuntu-24.04 is really bad. This is going to cause a lot of painful debugging for a lot of people because of this inconsistency causing intermediate but not repeatable failures.

Repro steps

1. Prepare a workflow which tries to install a python dependency using PIP and targets ubuntu-24.04.
2. Observe the error.

REMEDIATION:

1. Prepare a workflow with steps to install python (setup-python) and then tries to use PIP. This workflow should target ubuntu-24.04.
2. Observe no error and the machines are all happy.