python2.7 will be removed from the images on June 12, 2023

[mikhailkoliada]

Breaking changes

Python 2.7 will be removed from the images' tool cache.

Target date

The image rollout will start on June 12, 2023 and take 3-4 days.

The motivation for the changes

Python2.7 is not supported since January 1, 2020.

Possible impact

If your builds depend on python2.7 they will be broken.

Platforms affected

• Azure DevOps
• GitHub Actions

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• Windows Server 2019
• Windows Server 2022

Mitigation ways

No specific steps should be taken.

[vitalkanev]

Python2.7 is not supported since January 1, 2022.

Correction: it's 2020, not 2022. The linked documents don't even mention 2022.

[mikhailkoliada]

@vitalkanev true that! Fixed, thanks :)

[rtibbles]

Can I ask for clarification of the exact implications of this - is this just being removed from the runners tool cache, but would still be installable using the @setup-python action, or does this change have implications for the correct operation of @setup-python action as well?

[rtibbles]

Bumping the question above, as the implications of this still aren't entirely clear.

[mboudreau]

This rollout seems to have affected some builds with Wine: #4589

Is it possible to request the old image version as part of a build?

[rtibbles]

Any more information here? I had assumed as the date had passed this was not going to cause us any issues, but on checking back I see the rollout has been delayed. Could we get clarity before this is rolled out?

[rouilj]

Alternative: You can use Docker on GitHub Actions (and I expect Azure Pipelines) to test whatever version you need and maintain it yourself.
[...]
I'll soon post my Dockerfile to a repo under the coatl-dev org, so stay tuned.

@thecesrom thanks for dong this. Do you use any external services in your testing? My github CI action deploys and does custom configuration for postgresql, mysql, and redis to be able to test the Python application.

I guess I am going to have to:

• figure out how to make my app running in your container talk to these services running outside the container
• or build customized docker containers for all these services and spin all of them up and down for every test.

Sadly it's many hours of non-productive work either way.

[rtibbles]

Serious question: how much more time do you need?

To give some perspective on this - we have continued to support Python 2.7 with https://github.com/learningequality/kolibri based on our telemetry data which suggests that we still have a small but significant (roughly 2%) of active installed devices that are using Python 2.7. In addition, as our primary target is offline usage, there is the potential for a considerably larger number of offline users who are less able to run up to date Python versions.

We are in the process of deprecating Python 2.7 now that we have got down to only ~2% of recorded pingbacks, but we are also highly conscious of wanting to support the widest range of hardware and software we can.

This doesn't mean that you need to change course here - we can work around it until we are ready, but just wanted to give some additional perspective on why we are still actively using Python 2.7.

[rouilj]

The software I support has per site programming in Python. Business logic is written in Python and needs to be upgraded/rewritten/tested under python 3 for each tracker deployment.

Deprecation for Python 2 started with the first release that supported Python 3 in 2020.

My original plan was to support python 2 until the 2020 long term support (LTS) distros went out of support. That is in 2025 for Ubuntu and similarly for Debian 9. RedHat support was expected to end after full support ended again in 5 years. Less than a year ago I had somebody upgrade to python 3 because they went to a new platform that dropped support for python 2. I expected similar platform upgrades to drive movement to Python 3.

Obviously I'll have to make a decision about the 2024 and 2025 version support for python 2.

[mikhailkoliada]

Removed from the image.

[scoder]

As 2.7 is EOL, it doesn't get any updates or fixes, so the maintenance burden should be low.

I second that. The work involved on your side to "keep it working" might be a little higher now that it actually was removed, but I still don't understand why you have decided to replace an "it's there, it still works, no changes" maintenance burden with a "please switch to an entirely different setup and bring that to work" for all of your users that still need it. That seems a very costly step overall.

Serious question: how much more time do you need?

It seems like another year would have helped. Many projects have been removing Py2 support gradually only during the last year, and it's still going up the dependency chains. Removing support now will probably accelerate that ("sorry, we can't test it any more, and don't have the time to add back the support"), but it's also a hard blow.

IMHO, the removal now is still too early. Reading the discussion above, the deadline seems entirely arbitrary. So why not move it by another year again?

[eli-schwartz]

My solution for Windows was to simply download https://www.python.org/ftp/python/2.7.18/python-2.7.18.amd64.msi and run msiexec.exe on it. I do not think any maintenance burden is involved here. Probably, the VM image is slightly smaller without this...

For Linux there might be a slightly higher maintenance burden on the runner-images although I would have assumed the only real, meaningful difference is a version number on the list of source tarballs that are looped over, downloaded, and ./configure && make && make installed.

[anthonyeden]

For anyone who still needs to run Python 2.7 on Windows in GitHub actions, here's an Actions step I came up with after a lot of trial and error:

      - name: Install Python 2.7.18
        shell: cmd
        run: |
          choco install wget --no-progress
          wget -nv "https://www.python.org/ftp/python/2.7.18/python-2.7.18.amd64.msi"
          start /wait msiexec.exe /passive /i python-2.7.18.amd64.msi /norestart /L*V "python_install.log" ADDLOCAL=ALL ALLUSERS=1 TARGETDIR=c:\python27
          type "python_install.log"

This step takes about 60 secs to run for me.

[cesarcoatl]

@anthonyeden, perhaps you could try choco install python2.

On the other hand, I've created an action for publishing Python2-only packages available here, and a Docker image with Python 3.10 and 2.7 called coatldev/six.