python2.7 will be removed from the python-versions on June 19

[dmitry-shibanov]

Breaking changes

Hello everyone. The Python 2.7.x will be removed from python-versions and it won't be possible to set up Python 2.7.x by setup-python.

The motivation for the changes

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

[rtibbles]

Hi @dmitry-shibanov - do you have any recommended ways to mitigate this for those of us that cannot remove usage of Python 2.7 from our Github Actions before the June 19th deadline?

[bernhardkaindl]

@dmitry-shibanov

• February 2020: GitHub said they'd remove 2.7 from Actions. https://github.blog/changelog/2020-02-27-github-actions-breaking-change-python-2-being-removed-from-all-virtual-environments/
• March 2020: GitHub said they'd exceptionally keep 2.7 longer. Effect of python 2 sunset on setup-python #63 (comment)
• November 2022: GitHub removed 2.7 from Actions.
• December 2022: GitHub added 2.7 back to Actions.
• April 2023: GitHub announced they'll be removing 2.7 in May 2023.

It has already been delayed.

@konradpabjan I hope this can be cancelled like the previous times. I think there will be customer backslash again which would not be justified.

There is no point in removing it.

Linux Distros like Ubuntu 20.04 which contain Python2.7 support Python 2.7 for many many years to come. Canonical will maintain it until April 2025, and it will have emergency security updates in 20.04 until April 2030. Similar for Red Hat and SUSE.

[boegel]

We started hitting this today already (1 June 2023), leading to:

Error: Version 2.7 with arch x64 not found

Support for Python 2.7 is deprecated in our project already, so we'll just stop testing on top of Python 2.7 and not lose sleep over it, but it would be nice if there's a documented/recommended alternative for people that do still want to keep testing on top of Python 2.7 in the near future.

[hugovk]

There's a community-maintained Dockerfile in the works: actions/runner-images#7401 (comment)

[tzortzispanagiotis]

Guys, do we have a suggested workaround? This is a huge deal for us - whole project depends on python 2 so we would not be able to deploy anything. If anyone has an idea, please help :)

[tzortzispanagiotis]

To anyone concerned:
You can continue using github-hosted runners with python2.7 by running the job inside a container.
e.g. I used python:2.7-buster image and everything works out just fine.

No need to use setup-python or be dependent of runner-images anymore.

[MatteoH2O1999]

If you don't need 2.7 for windows, you could use my custom action MatteoH2O1999/setup-python.
This action tries to build from source all Python versions that actions/setup-python does not support.
It also allows to cache built versions so that after the first run, installation time is really low.
For an example of a run see this workflow.

Windows support is in the works but no ETA (note that for Windows it will still allow for versions that are supported by 'actions/setup-python' to successfully complete).

[dimitrisr]

To anyone concerned: You can continue using github-hosted runners with python2.7 by running the job inside a container. e.g. I used python:2.7-buster image and everything works out just fine.

Hello @tzortzispanagiotis, could you please provide an example for this? 🙏

Thanks in advance.

[tzortzispanagiotis]

Hello @dimitrisr,

In order to overcome this I modified:

runs-on: ubuntu-20.04

to

runs-on: ubuntu-20.04
    container:
      image: python:2.7.18-buster

So that the job is run using a github-hosted runner, but inside the python2.7-buster container, which has set up python2.7

Then I started running the pipeline and started fixing everything that was broken (because the container does not have things as sudo, so you have to install it with a command)

Also, If your CI pipeline has other services (e.g. mysql) that run inside a container, now that the whole job is running inside a container, the service container is accessible not through localhost (127.0.0.1), but through the service name.

I hope I was helpful!

[dimitrisr]

Thank you @tzortzispanagiotis, this was really helpful! I was able to run the actions successfully :)

[MatteoH2O1999]

This seems like a nice, minimal way to keep testing legacy Python... https://github.com/dateutil/dateutil/blob/0586f4afa26fc6799128d98d4f97a49c7d6ab314/.github/workflows/validate.yml#L39-L56

Yeah but it still misses the point: why should Github go out of their way to make sure that something that worked before does not work anymore, while they could have simply added a warning "Hey, Python 2 is deprecated and you should not rely on it. If it works great, if it doesn't too bad, you're on your own"?

Once again, not arguing that Python 2 isn't deprecated, it obviously is, but saying that this is a nice way to sunset anything more than a university project is not really a great flag regarding Github's likeliness of following THEIR OWN GUIDELINES on versioning in the future.

[bernhardkaindl]

Yeah but it still misses the point: why should Github go out of their way to make sure that something that worked before does not work anymore, while they could have simply added a warning "Hey, Python 2 is deprecated and you should not rely on it. If it works great, if it doesn't too bad, you're on your own"?

Once again, not arguing that Python 2 isn't deprecated, it obviously is, but saying that this is a nice way to sunset anything more than a university project is not really a great flag regarding Github's likeliness of following THEIR OWN GUIDELINES on versioning in the future.

@MatteoH2O1999: To me, it looks like GitHub is under the influence of a very vocal Python Core developer who simply declared in essence that he is not going to maintain Python 2.7 for being too much work.

Told him in a comment somewhere here on GitHub that I did not see anything that would backup his claims and that simply not removing Python2 would not cost him anything, but he still pressed on and did not answer any of my stipulations that it's not an issue to still provide it as it is, is just fine.

I could not these comments quickly, but at least as far as public comments on GitHub, I could only find this single guy taking a public stance, but this guy was at least verbally nuking it.

[JamesParrott]

https://github.com/LizardByte/setup-python-action

That works great, and on windows runner images too (unlike my docker suggestion). Thanks so much @ReenigneArcher & @LizardByte!