Repository navigation
python-version-file chooses most recent supported Python version, not the oldest supported version #774
Description
Description:
I'm using python-version-file: pyproject.toml to specify which Python version to use. My pyproject.toml is pretty standard poetry config, with a python = "^3.8" marker.
However, when using the action with such a config, it uses the most recent supported Python version. This doesn't make much sense to me, as Python code is generally forwards-compatible (except numpy/scipy/etc), but it is not backwards-compatible, as there are features in newer versions that aren't supported in previous versions (which is why I always run my CI jobs with the lowest supported Python minor version).
I expected it to pick the lowest supported minor version with the highest patch. Such that ^3.8 picks 3.8.15, not 3.12.0.
Justification:
With the current behavior, using python-version-file with a pyproject.toml that has a Python version marker specified with ^ (common) would basically be a no-op, as it will pick the same version as if python-version-file isn't specified at all.
Thus, I don't see much use for the current behavior, and would like to see it changed.
One option is to add a config to choose the behavior, which would prevent breakage in people's existing workflows. (as I did in #775)
Are you willing to submit a PR?
Yes! Done in #775
Activity
dmitry-shibanov commentedon Dec 6, 2023
Hello @ErikBjare. Thank you for your feature request. It is an expected behaviour for caret symbol to pick the latest minor version. I think that the action should not directly interfer with python-version to change it somehow. You can use python-version input to specify different python versions as ~3.8 or 3.8 to get the proposed behaviour.
For now I'm going to close the feature request.
ErikBjare commentedon Dec 6, 2023
@dmitry-shibanov Did you see my PR?
The current behavior really makes the
python-version-filekinda worthless for use with Poetrypyproject.toml, for the reasons previously stated.I'm aware I can just set the
python-versionlike that, as that's what I've been doing, but I'd like to keep the Python version specified in a single place (aspython-version-fileenables).I'd appreciate if you could give this a second consideration and reopen the issue, as this really surprised me and the current behavior is (imo) not usable.
It's a small and non-breaking change to adopt the additional configuration added in the PR.
dmitry-shibanov commentedon Dec 6, 2023
It is an expected behaviour from the poetry side that they use caret notation. In this case poetry follows SemVer notation format that is why it is an expected behaviour to take the latest minor version. Caret and tilde are both valid variants for setup-python and poetry but they take different ranges. The action should not change the actual supported format from poetry through another input. You can try to use
poetry env use <version>command, python-version input or change caret to tilde directly in the toml file.ErikBjare commentedon Dec 6, 2023
@dmitry-shibanov I am aware of all this, and I still feel you are misunderstanding my point here.
I guess I'll just use my own fork of the action.
Andrej730 commentedon Sep 3, 2026
Also got the same idea.
My reasoning - I use
setup-pythonin the workflow that's running the tests and wanted to cover the minimum allowed Python version to ensure we don't rely on any new Python features.ErikBjare commentedon Sep 3, 2026
@Andrej730 Yeah, looks like two separate maintainers (#775 (comment)) looked at this and didn't understand what I was trying to do here. Slightly frustrating to have been unable to explain it clearly enough, apparently.
It would really have been nice to have, would still clean up my CI in a way the suggested workarounds can't.
v-gowridurgad commentedon Sep 22, 2026
Hi @ErikBjare, we did understand the use case you were describing.
The reason we're still hesitant to implement it is consistency. setup-python currently follows the standard highest-satisfying resolution behavior from semver range semantics. Introducing a lowest-version mode only here would mean the same specifier no longer resolves the same way across the action, which makes the declared version harder to reason about and failures harder to debug.
In PR #775, the proposed approach rewrites operators like ^ and >= to ~ before resolution. Per node-semver, ^3.8 is >=3.8.0 <4.0.0-0 while ~3.8 is >=3.8.0 <3.9.0-0 , so that rewrite narrows the declared range itself, rather than preserving the original range and only changing how a version is selected from it. Even setting the broader feature-scope question aside, that means the specific implementation is not something we would be able to take as-is.
Hope this clarifies.