Hi @molson504x , Thanks for bringing this issue to our notice. Will analyze the same and provide an update.

To unblock yourself, please consider using ubuntu-22.04 runner in your workflow.

runs-on: ubuntu-22.04

Cause :
ubuntu-24.04 runner uses python 3.12 as the default installation, which has a marker file EXTERNALLY-MANAGED.
This file insists and tolls like pip install packages within a virtual environment.

To unblock yourself, please consider using ubuntu-22.04 runner in your workflow.

runs-on: ubuntu-22.04

Cause : ubuntu-24.04 runner uses python 3.12 as the default installation, which has a marker file EXTERNALLY-MANAGED. This file insists and tolls like pip install packages within a virtual environment.

Hey @subir0071 - yeah, that was one of our solutions. We actually did it a different way. We added a setup-python step to the workflow, and since that installs a python interpreter that is not externally managed it solves the problem. HOWEVER, my main issue with this is it's a breaking change which is not documented, and it is an intermittent breaking change due to the phased rollout of updating the ubuntu-latest tag. This breaking change should really be documented somewhere.

OR - even better would be to package the runner image with a python interpreter which is not externally managed.

Hi @molson504x , Hope you are able to progress with your CI/CD workload. Kindly suggest on the closure of this ticket. Thanks.

Hello @subir0071 👋

Are you suggesting that the issue will not be managed in the ubuntu-24.04 GitHub image, and it, by default, will always trigger an error when doing a pip install <something> ?

I can confirm that standard Ubuntu 24.04 throws this error as well. It will be necessary to replace the standard Python installation, whether by GitHub or by an action, to avoid it.

This broke our builds too

...either needs to be resolved or documented before I will accept closing this issue.

Agreed. The image documentation page lists:

Language and Runtime

• ...
• Python 3.10.12
• ...

Package Management

• ...
• Pip 24.0
• ...

Without any notes, it feels misleading to me to have this listed yet pip install... immediately raises an error on the image.

I would find it most convenient to be able to continue usage as with 22.04, but a documentation update seems reasonable.

for what it's worth, pipenv install seemed to also trigger this issue. So, I thought I was using a virtual environment.

I was not able to reproduce this using an ubuntu:24.04 docker image. (i.e. pipenv install succeeded). I'll probably use the runs-on: ubuntu-22.04 instead.

@subir0071 - Based on the post in #10636 I'm willing to close this, however this should still be addressed in documentation about ubuntu-24.04 runners or should be addressed by installing a non-system-managed python interpreter in the image.

Comment, for reference:

Hey everyone - thank you for your input. Based on community feedback we have decided to rollback the ubuntu-latest migration. All runs on ubuntu-latest will go back to Ubuntu-22 while we work out the issues with the image. We apologize for any service disruption you all may have had, and appreciate everyone’s feedback and patience. The rollback will be completed in the next hour.

To give some context for the changes we made - our images have become very large over the past 2 years and we were trying to free up some space to give us some breathing room going forward. There is currently no extra free space left for installing any more tooling, while still maintaining our free space SLA of 14gb. The size of the image also impacts performance of the VMs as well. Since a new OS is always a cutover, we took the opportunity to free up some space. Clearly this was not the right approach, and we apologize for the pain we have caused.

We will re-evaluate our communication and rollout strategy before beginning this migration again.

Closing this issue, per comment in #10636 - rolling back ubuntu-latest to reference ubuntu-22.04 runner image.

Yes, I know this has been closed, but I want to provide a few examples supporting my stance on this.

Using an action or a venv to install a private/safe Python was always the correct thing to do, and Canonical as of 24.04 is enforcing it.

• Back in 2006-2007 a requested update to a Perl module in our environment broke (Open)SuSE's yast.
• Roughly a decade later, I tried to help someone repair their Ubuntu system after upgrading a Python module that broke apt-get. (Ultimately they ended up reinstalling; the broken module broke post-install scripts as well, so we couldn't even fall back to dselect/dpkg.)

Red Hat / Fedora avoid this by shipping their own minimal Python install that system tools use, avoiding the user-facing one, but I don't think this scales especially if you're trying to keep image sizes down. The only reliable way to avoid it is to assume the system-provided language packages are intended to work with the system and install your own if you will be upgrading or installing additional packages not via the system's package manager.

Using an action or a venv to install a private/safe Python was always the correct thing to do, and Canonical as of 24.04 is enforcing it.

This is both wrong and fallaciously wrong.

Inside of a temporary container, all the reasons for installing additional python interpreters just to have a different environment, are not applicable. The original rationale for this "Externally Managed" change even notes that scenario. But "Ubuntu Linux" doesn't know when it is being used "as a container", that's been deferred to container vendors such as Github Actions to fix by deleting the marker file. Of course, no container vendors bother to do so.

@eli-schwartz wrote

Inside of a temporary container, all the reasons for installing additional python interpreters just to have a different environment, are not applicable. …

I would agree, and note that specifically, at the end of this section of the Python docs:

In certain contexts, such as single-application container images that aren’t updated after creation, a distributor may choose not to ship an EXTERNALLY-MANAGED file, so that users can install whatever they like (as they can today) without having to manually override this rule.

However, the recommendation section here recommends to

Keep the marker file in container images

Just for visibility here, this issue will be coming back:

• [Ubuntu 24] Removal of Temporary Workaround for Pip Install on Python Default Environment from January 10 ,2025 #10897