Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dmitry-shibanov opened this issue May 23, 2023 · 40 comments
Closed

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

dmitry-shibanov opened this issue May 23, 2023 · 40 comments

Comments

@dmitry-shibanov
Copy link
Contributor

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
Copy link

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
Copy link

bernhardkaindl commented May 30, 2023

@dmitry-shibanov

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
Copy link

boegel commented Jun 1, 2023

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
Copy link
Contributor

hugovk commented Jun 1, 2023

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

mathiascode added a commit to devsnd/tinytag that referenced this issue Jun 2, 2023
Python 2.7 will not be supported by GitHub Actions any longer: actions/setup-python#672

We can continue using PyPy 2.7 to test Python 2 until we drop support in tinytag 2.0.0.
@tzortzispanagiotis
Copy link

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
Copy link

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
Copy link

MatteoH2O1999 commented Jun 8, 2023

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
Copy link

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
Copy link

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
Copy link

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

fajpunk added a commit to fajpunk/ansible-merge-vars that referenced this issue Dec 18, 2023
This PR gets the tests to pass with all the latest minor versions of all currently existing Python and Ansible versions.  It was not pleasant work. There have been a lot of Ansible versions and a lot of Python versions and a lot of changes to... just about everything involved here... since I last had the time to work on this!

By some miracle, the plugin itself has *NOT* needed *ANY* changes.  It still totally works.

* Add new Python and Ansible version combos to the generated tox.ini
* Restrict the Jinja2 version for some combos because it was [too broadly specified in the Ansible deps](ansible/ansible#77356)
* Remove the [deprecated](ansible/ansible#75828) `Templar.set_available_variables` method in a test util function (luckily there is another way to do this that works for all Ansible versions)
* Run each job in official python images: the [setup-python](https://github.com/actions/setup-python) action [no longer supports 2.7](actions/setup-python#672), and not all 3.x versions can be installed in the same Ubuntu runner anyway.
* Don't use [tox-gh-actions](https://pypi.org/project/tox-gh-actions/): the version that supports running in containers isn't compatible with all of the python versions that we need [issue](https://github.com/ymyzk/tox-gh-actions/pull/114/files)
* Restrict tox to a version that both supports Python 2.7 and supports filtering envs
* Explicitly call out `asdf` dependency for getting all tox combos to pass locally
fajpunk added a commit to fajpunk/ansible-merge-vars that referenced this issue Dec 18, 2023
This PR gets the tests to pass with all the latest minor versions of all currently existing Python and Ansible versions.  It was not pleasant work. There have been a lot of Ansible versions and a lot of Python versions and a lot of changes to... just about everything involved here... since I last had the time to work on this!

By some miracle, the plugin itself has *NOT* needed *ANY* changes.  It still totally works.

* Add new Python and Ansible version combos to the generated tox.ini
* Restrict the Jinja2 version for some combos because it was [too broadly specified in the Ansible deps](ansible/ansible#77356)
* Remove the [deprecated](ansible/ansible#75828) `Templar.set_available_variables` method in a test util function (luckily there is another way to do this that works for all Ansible versions)
* Run each job in official python images: the [setup-python](https://github.com/actions/setup-python) action [no longer supports 2.7](actions/setup-python#672), and not all 3.x versions can be installed in the same Ubuntu runner anyway.
* Don't use [tox-gh-actions](https://pypi.org/project/tox-gh-actions/): the version that supports running in containers isn't compatible with all of the python versions that we need [issue](https://github.com/ymyzk/tox-gh-actions/pull/114/files)
* Restrict tox to a version that both supports Python 2.7 and supports filtering envs
* Explicitly call out `asdf` dependency for getting all tox combos to pass locally
* Add a link to [a proposed alternative way to do this](leapfrogonline#43) with pure Ansible to the Readme
fajpunk added a commit to fajpunk/ansible-merge-vars that referenced this issue Dec 18, 2023
This PR gets the tests to pass with all the latest minor versions of all currently existing Python and Ansible versions.  It was not pleasant work. There have been a lot of Ansible versions and a lot of Python versions and a lot of changes to... just about everything involved here... since I last had the time to work on this!

By some miracle, the plugin itself has *NOT* needed *ANY* changes.  It still totally works.

* Add new Python and Ansible version combos to the generated tox.ini
* Restrict the Jinja2 version for some combos because it was [too broadly specified in the Ansible deps](ansible/ansible#77356)
* Remove the [deprecated](ansible/ansible#75828) `Templar.set_available_variables` method in a test util function (luckily there is another way to do this that works for all Ansible versions)
* Run each job in official python images: the [setup-python](https://github.com/actions/setup-python) action [no longer supports 2.7](actions/setup-python#672), and not all 3.x versions can be installed in the same Ubuntu runner anyway.
* Don't use [tox-gh-actions](https://pypi.org/project/tox-gh-actions/): the version that supports running in containers isn't compatible with all of the python versions that we need [issue](https://github.com/ymyzk/tox-gh-actions/pull/114/files)
* Restrict tox to a version that both supports Python 2.7 and supports filtering envs
* Explicitly call out `asdf` dependency for getting all tox combos to pass locally
* Add a link to [a proposed alternative way to do this](leapfrogonline#43) with pure Ansible to the Readme
fajpunk added a commit to fajpunk/ansible-merge-vars that referenced this issue Dec 18, 2023
This PR gets the tests to pass with all the latest minor versions of all currently existing Python and Ansible versions.  It was not pleasant work. There have been a lot of Ansible versions and a lot of Python versions and a lot of changes to... just about everything involved here... since I last had the time to work on this!

By some miracle, the plugin itself has *NOT* needed *ANY* changes.  It still totally works.

* Add new Python and Ansible version combos to the generated tox.ini
* Restrict the Jinja2 version for some combos because it was [too broadly specified in the Ansible deps](ansible/ansible#77356)
* Remove the [deprecated](ansible/ansible#75828) `Templar.set_available_variables` method in a test util function (luckily there is another way to do this that works for all Ansible versions)
* Run each job in official python images: the [setup-python](https://github.com/actions/setup-python) action [no longer supports 2.7](actions/setup-python#672), and not all 3.x versions can be installed in the same Ubuntu runner anyway.
* Don't use [tox-gh-actions](https://pypi.org/project/tox-gh-actions/): the version that supports running in containers isn't compatible with all of the python versions that we need [issue](https://github.com/ymyzk/tox-gh-actions/pull/114/files)
* Restrict tox to a version that both supports Python 2.7 and supports filtering envs
* Explicitly call out `asdf` dependency for getting all tox combos to pass locally
* Add a link to [a proposed alternative way to do this](leapfrogonline#43) with pure Ansible to the Readme
fajpunk added a commit to fajpunk/ansible-merge-vars that referenced this issue Dec 18, 2023
This PR gets the tests to pass with all the latest minor versions of all currently existing Python and Ansible versions.  It was not pleasant work. There have been a lot of Ansible versions and a lot of Python versions and a lot of changes to... just about everything involved here... since I last had the time to work on this!

By some miracle, the plugin itself has *NOT* needed *ANY* changes.  It still totally works.

* Add new Python and Ansible version combos to the generated tox.ini
* Restrict the Jinja2 version for some combos because it was [too broadly specified in the Ansible deps](ansible/ansible#77356)
* Remove the [deprecated](ansible/ansible#75828) `Templar.set_available_variables` method in a test util function (luckily there is another way to do this that works for all Ansible versions)
* Run each job in official python images: the [setup-python](https://github.com/actions/setup-python) action [no longer supports 2.7](actions/setup-python#672), and not all 3.x versions can be installed in the same Ubuntu runner anyway.
* Don't use [tox-gh-actions](https://pypi.org/project/tox-gh-actions/): the version that supports running in containers isn't compatible with all of the python versions that we need [issue](https://github.com/ymyzk/tox-gh-actions/pull/114/files)
* Restrict tox to a version that both supports Python 2.7 and supports filtering envs
* Explicitly call out `asdf` dependency for getting all tox combos to pass locally
* Add a link to [a proposed alternative way to do this](leapfrogonline#43) with pure Ansible to the Readme
fajpunk added a commit to fajpunk/ansible-merge-vars that referenced this issue Dec 18, 2023
This PR gets the tests to pass with all the latest minor versions of all currently existing Python and Ansible versions.  It was not pleasant work. There have been a lot of Ansible versions and a lot of Python versions and a lot of changes to... just about everything involved here... since I last had the time to work on this!

By some miracle, the plugin itself has *NOT* needed *ANY* changes.  It still totally works.

* Add new Python and Ansible version combos to the generated tox.ini
* Restrict the Jinja2 version for some combos because it was [too broadly specified in the Ansible deps](ansible/ansible#77356)
* Remove the [deprecated](ansible/ansible#75828) `Templar.set_available_variables` method in a test util function (luckily there is another way to do this that works for all Ansible versions)
* Run each job in official python images: the [setup-python](https://github.com/actions/setup-python) action [no longer supports 2.7](actions/setup-python#672), and not all 3.x versions can be installed in the same Ubuntu runner anyway.
* Don't use [tox-gh-actions](https://pypi.org/project/tox-gh-actions/): the version that supports running in containers isn't compatible with all of the python versions that we need [issue](https://github.com/ymyzk/tox-gh-actions/pull/114/files)
* Restrict tox to a version that both supports Python 2.7 and supports filtering envs
* Explicitly call out `asdf` dependency for getting all tox combos to pass locally
* Add a link to [a proposed alternative way to do this](leapfrogonline#43) with pure Ansible to the Readme
fajpunk added a commit to fajpunk/ansible-merge-vars that referenced this issue Dec 18, 2023
This PR gets the tests to pass with all the latest minor versions of all currently existing Python and Ansible versions.  It was not pleasant work. There have been a lot of Ansible versions and a lot of Python versions and a lot of changes to... just about everything involved here... since I last had the time to work on this!

By some miracle, the plugin itself has *NOT* needed *ANY* changes.  It still totally works.

* Add new Python and Ansible version combos to the generated tox.ini
* Restrict the Jinja2 version for some combos because it was [too broadly specified in the Ansible deps](ansible/ansible#77356)
* Remove the [deprecated](ansible/ansible#75828) `Templar.set_available_variables` method in a test util function (luckily there is another way to do this that works for all Ansible versions)
* Run each job in official python images: the [setup-python](https://github.com/actions/setup-python) action [no longer supports 2.7](actions/setup-python#672), and not all 3.x versions can be installed in the same Ubuntu runner anyway.
* Don't use [tox-gh-actions](https://pypi.org/project/tox-gh-actions/): the version that supports running in containers isn't compatible with all of the python versions that we need [issue](https://github.com/ymyzk/tox-gh-actions/pull/114/files)
* Restrict tox to a version that both supports Python 2.7 and supports filtering envs
* Explicitly call out `asdf` dependency for getting all tox combos to pass locally
* Add a link to [a proposed alternative way to do this](leapfrogonline#43) with pure Ansible to the Readme
fajpunk added a commit to fajpunk/ansible-merge-vars that referenced this issue Dec 18, 2023
This PR gets the tests to pass with all the latest minor versions of all currently existing Python and Ansible versions.  It was not pleasant work. There have been a lot of Ansible versions and a lot of Python versions and a lot of changes to... just about everything involved here... since I last had the time to work on this!

By some miracle, the plugin itself has *NOT* needed *ANY* changes.  It still totally works.

* Add new Python and Ansible version combos to the generated tox.ini
* Restrict the Jinja2 version for some combos because it was [too broadly specified in the Ansible deps](ansible/ansible#77356)
* Remove the [deprecated](ansible/ansible#75828) `Templar.set_available_variables` method in a test util function (luckily there is another way to do this that works for all Ansible versions)
* Run each job in official python images: the [setup-python](https://github.com/actions/setup-python) action [no longer supports 2.7](actions/setup-python#672), and not all 3.x versions can be installed in the same Ubuntu runner anyway.
* Don't use [tox-gh-actions](https://pypi.org/project/tox-gh-actions/): the version that supports running in containers isn't compatible with all of the python versions that we need [issue](https://github.com/ymyzk/tox-gh-actions/pull/114/files)
* Restrict tox to a version that both supports Python 2.7 and supports filtering envs
* Explicitly call out `asdf` dependency for getting all tox combos to pass locally
* Add a link to [a proposed alternative way to do this](leapfrogonline#43) with pure Ansible to the Readme
rschwebel added a commit to rschwebel/nodeenv that referenced this issue Dec 19, 2023
Python 2.7 is long obsolete, deprecated and not supported any more.
Remove it from the tests. This test job is especially supposed to run on
ubuntu-20.04, which doesn't have Python 2.7 any more.

Without this patch, this workflow fails with:

  Warning: The support for python 2.7 will be removed on June 19. Related issue: actions/setup-python#672
  Version 2.7 was not found in the local cache
  Error: The version '2.7' with architecture 'x64' was not found for Ubuntu 20.04.
  The list of all available versions can be found here: https://raw.githubusercontent.com/actions/python-versions/main/versions-manifest.json
@priyagupta108 priyagupta108 unpinned this issue Jan 16, 2024
@JamesParrott
Copy link

JamesParrott commented Jan 16, 2024

That's fantastic @tzortzispanagiotis. Effective, elegant, and cuts out a dependency whose maintainers have let down users of projects that still need to support Python 2. Running in a container works as part of a matrix strategy too, e.g.:

jobs:
  build:

    strategy:
      matrix:
        python-version: ["2.7.18", "3.6.15", "3.7.17", "3.8.18", "3.9.18", "3.10.13", "3.11.7", "3.12.1", "3.13.0a2"]

    runs-on: ubuntu-20.04
    container:
      image: python:${{ matrix.python-version }}-slim

    steps:

I've specified slim images (which are based on a range of Debian releases) pinned to the latest minor version I could find as of yesterday (and one for an alpha pre-release of 3.13). Alternatively, tags for any images with the required Python version installed could be used instead of actions/setup-python. These are the official Python Docker image tags (requires logging in to Docker hub).

In general there could be other side effects from switching environments to a Docker container, instead of a Github VM image. But it's well worth trying, especially for uncomplicated projects with straightforward CI tasks, that don't require one of the pre-installed packages on Github VM runner images (required packages might just have to be installed in the Docker container by other means).

@cclauss
Copy link
Contributor

cclauss commented Jan 16, 2024

@JamesParrott You are overthinking it because python2 is still available on ubuntu-20.04
% python2 --version

Python 2.7.18

On ubuntu-20.04...

      - if: matrix.python-version == '2.7'
        run: sudo ln -sf /usr/bin/python2.7 /usr/bin/python

Python 2 died 1,476 days ago on 1/1/2020 so enabling your customers to continue using it is a substantial security risk.

@tomato42
Copy link

Python 2 died 1,476 days ago on 1/1/2020 so enabling your customers to continue using it is a substantial security risk.

just because upstream doesn't support Python 2 doesn't mean that nobody offers security updates to Python 2

@JamesParrott
Copy link

JamesParrott commented Jan 16, 2024

@cclauss I just copied Ubuntu 20.04 from Panagiotis. It will work using ubuntu-latest just as well.

The advantage of using a matrix strategy is to reduce code duplication, to try to ensure as far as possible, that the exact same test code is run in CI, regardless of the Python version.

Running in containers from specifically tagged python docker images is more future proof, and doesn't requiring writing code for the special case where the Python version you want happens to be the global system Python, that anyway will only work until the Ubuntu 20.04 Github Actions runner image is dropped (like the Ubuntu 19 ones were).

I'm well aware of the security issues too, thank you Christian. In an ideal world, I agree. The Python 2 projects are not security critical. But they still deserve working CI systems, and tests.

@ReenigneArcher
Copy link

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

Works on all GitHub hosted runners (Windows, Linux, macOS... and all versions).

It uses the default action, unless you specify 2.7 as the version, allowing you to easily use a single action in matrix runs.

@jvanasco
Copy link

"2.7 is insecure for your clients" seems to be the response by amateur coders who do understand that large software projects and legacy systems often can not be upgraded to 3.x - or that these systems are often isolated and are not susceptible to the attack vectors of concern.

While there are workarounds to switch from this build to an OS build or third party system, I stress again what myself and others have stated above: Github could have and should have simply not provided Python 2.7 on new and future builds to sunset this system. Instead, Github violated their customer promise, industry best-practices, and the entire concept of versioning by dedicated resources to break all existing builds by removing Python2.7 from legacy versions.

@MatteoH2O1999
Copy link

MatteoH2O1999 commented Jan 20, 2024

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
Copy link

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.

jwilk added a commit to jwilk/python-syntax-errors that referenced this issue Jan 26, 2024
Fixes:

    ##[warning]The support for python 2.7 will be removed on June 19. Related issue: actions/setup-python#672
    Version 2.7 was not found in the local cache
    ##[error]The version '2.7' with architecture 'x64' was not found for Ubuntu 20.04.
dpp-name added a commit to dpp-name/python-mammoth that referenced this issue Feb 5, 2024
@JamesParrott
Copy link

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!

yuangezhizao added a commit to yuangezhizao/yabgp that referenced this issue Mar 6, 2024
zlpqingmei pushed a commit to smartbgp/yabgp that referenced this issue Mar 6, 2024
…in BGP UPDATE Message (#167)

* 🎨 Style(__init__.py): replace "Sid" with "SID"

* ✨ Feat(bgpprefixsid.py): add support for parsing the Path Attribute: BGP Prefix-SID (Type 40)

Refer:
https://github.com/Exa-Networks/exabgp/blob/main/src/exabgp/bgp/message/update/attribute/sr/prefixsid.py

* ✅ Test(test_bgpprefixsid.py): add unittest and format result

* 💚 Fix-ci(ci.yml): remove Python 2.7.x from the CI matrix
Refer: actions/setup-python#672

* 🔥 Prune(.travis.yml): remove Travis CI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests