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
Comments
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? |
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. |
We started hitting this today already (1 June 2023), leading to:
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. |
There's a community-maintained Dockerfile in the works: actions/runner-images#7401 (comment) |
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.
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 :) |
To anyone concerned: No need to use setup-python or be dependent of runner-images anymore. |
If you don't need 2.7 for windows, you could use my custom action MatteoH2O1999/setup-python. 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). |
Hello @tzortzispanagiotis, could you please provide an example for this? 🙏 Thanks in advance. |
Hello @dimitrisr, In order to overcome this I modified:
to
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! |
Thank you @tzortzispanagiotis, this was really helpful! I was able to run the actions successfully :) |
Because of the announcement of removal of Python 2.7 for setup-python in actions/setup-python#672, use a wrapper for setup-python which can build missing Python versions. Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
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
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
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
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
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
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
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
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
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.:
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). |
@JamesParrott You are overthinking it because
On - 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. |
just because upstream doesn't support Python 2 doesn't mean that nobody offers security updates to Python 2 |
@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. |
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 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. |
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. |
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.
That works great, and on windows runner images too (unlike my docker suggestion). Thanks so much @ReenigneArcher & @LizardByte! |
…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
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.
The text was updated successfully, but these errors were encountered: