-
Notifications
You must be signed in to change notification settings - Fork 567
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
python-version-file
chooses most recent supported Python version, not the oldest supported version
#774
Comments
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. |
@dmitry-shibanov Did you see my PR? The current behavior really makes the I'm aware I can just set the 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. |
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 |
@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. |
Description:
I'm using
python-version-file: pyproject.toml
to specify which Python version to use. Mypyproject.toml
is pretty standard poetry config, with apython = "^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
picks3.8.15
, not3.12.0
.Justification:
With the current behavior, using
python-version-file
with apyproject.toml
that has a Python version marker specified with^
(common) would basically be a no-op, as it will pick the same version as ifpython-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
The text was updated successfully, but these errors were encountered: