actions
Option to setup the oldest available Python rather than the latest version when a range of version specified
Description: Describe your proposal.
When specifying the python-version with a version range or 3.x, the latest version will be installed.
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.7 - 3.13"
- name: Lint
run: pipx run pre-commit ...
This issue requests an opt-in option to let the action install the oldest major version available on the runner rather than the latest.
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.7 - 3.13"
oldest-first: true
Justification: Justification or a use case for your proposal.
Newer Python may introduce new syntax. The valid code that can run on the latest Python may contain syntax errors in older Python. For example, Python 3.12 supports more powerful f-strings.
$ cat test.py
lines = ['a', 'b', 'c']
string = f'The joined lines are:\n{"\n".join(lines)}'
print(string)
$ python3.12 test.py
The joined lines are:
a
b
c
$ python3.11 test.py
File "/home/PanXuehai/.../test.py", line 2
string = f'The joined lines are:\n{"\n".join(lines)}'
^
SyntaxError: f-string expression part cannot include a backslash
The linting tool may not complain about the backward incompatible code if the linter runs with the latest Python.
One solution is to pin an old Python in the CI manually. However, the GitHub-hosted runner image may be updated separately with actions/setup-python. Users cannot use:
runs-on: ubuntu-latest
steps:
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.7"
Because the CI will break when ubuntu-latest changes from ubuntu-22.04 to ubuntu-24.04.
- The version '3.7' with architecture 'x64' was not found for Ubuntu 24.04.
- The list of all available versions can be found here: https://raw.githubusercontent.com/actions/python-versions/main/versions-manifest.json
This request reduces the potential CI breakage for the two cases above.
Are you willing to submit a PR?
Hello @XuehaiPan, Thank you for this feature request. We will investigate it and get back to you as soon as we have some feedback.
Hello @XuehaiPan, Thank you for your suggestion. While we understand the need for compatibility with older versions of Python, we recommend upgrading your CI workflows to use non-EOL Python versions (such as 3.8, 3.9, or 3.10), as EOL (End of Life) versions are not supported after their 6-month EOL date and may introduce security risks and instability in your builds.
By using non-EOL versions, you ensure that your CI workflows are running on versions that are actively maintained and receive security updates. If needed, you can pin your workflows to a specific version to maintain consistency across different environments.
We appreciate your understanding and encourage you to reach out if you have any further questions!
If needed, you can pin your workflows to a specific version to maintain consistency across different environments.
I want to clarify the context of this feature request.
Developers can always pin and update the runner and Python version in their workflow file. But this needs actively watching the upstream image and the Python release. Once a new release is out or an old release support is removed, their workflow suddenly breaks and shows unrelated failure of the user code in CI. Project maintainers need to patch it immediately, and that requires extra maintenance effort.
A simple scenario of this feature request is a wildcarded Python pin:
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.x"
oldest-first: true # the oldest supported non-EOL version
Hello @XuehaiPan, Thank you for the clarification and for sharing your perspective on the maintenance challenges related to pinning Python versions in CI workflows.
We understand the value of minimizing disruptions caused by upstream image or Python version updates, and the convenience a feature like wildcard version pinning could offer. At the same time, encouraging users to adopt non-EOL Python versions helps maintain security, stability, and compatibility across workflows, which is critical for reliable CI/CD processes.
We appreciate the thoughtful suggestion around an oldest-first option to balance flexibility with stability. While this is not something we are currently planning to implement, your feedback is valuable, and we will continue to monitor it for possible future enhancements.
Thank you again for your input and for helping us improve the experience for all users. Please feel free to reach out with any further questions or ideas!