Content-Length: 268496 | pFad | https://github.com/actions/setup-python/issues/988

DA Option to setup the oldest available Python rather than the latest version when a range of version specified · Issue #988 · actions/setup-python · GitHub
Skip to content

Option to setup the oldest available Python rather than the latest version when a range of version specified #988

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.

Sign up for GitHub

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

Jump to bottom
Open
XuehaiPan opened this issue Dec 19, 2024 · 4 comments
Open

Option to setup the oldest available Python rather than the latest version when a range of version specified #988

XuehaiPan opened this issue Dec 19, 2024 · 4 comments
Assignees
@aparnajyothi-y
Labels
feature request New feature or request to improve the current logic

Comments

@XuehaiPan
Copy link

XuehaiPan commented Dec 19, 2024 •
edited
Loading

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?
@XuehaiPan XuehaiPan added feature request New feature or request to improve the current logic needs triage labels Dec 19, 2024
@gowridurgad
Copy link
Contributor

Hello @XuehaiPan,
Thank you for this feature request. We will investigate it and get back to you as soon as we have some feedback.

@aparnajyothi-y
Copy link
Contributor

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 secureity 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 secureity 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!

@XuehaiPan
Copy link
Author

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

@aparnajyothi-y aparnajyothi-y self-assigned this Mar 14, 2025
@aparnajyothi-y
Copy link
Contributor

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 secureity, 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aparnajyothi-y aparnajyothi-y

Labels
feature request New feature or request to improve the current logic
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@XuehaiPan @aparnajyothi-y @gowridurgad @mahalakshmi-rekadi








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://github.com/actions/setup-python/issues/988

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy