Fix handling of maximum python version in pick_python_cmd #3478
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the minor version is unset, only the major version must be checked.
Otherwise patch versions etc. must be ignored.
This allows:
3.7.4 for "max_py_majver=3" and "max_py_majver=3 max_py_minver=7"
However I'd argue that our current approach with
max_py_maj/minver
andreq_py_maj/minver
is error-prone anyway: It does not make sense to only specify a minor version for either. Hence I'd change that easyconfig parameter into a single one:required_python_version
which is a string like "3.7", same for the max version.This can then be converted to a
LooseVersion
and fully avoids the possibility of missing major versions as well as having only a single parameter instead of 2. We can convert the current parameters to the new one automatically and deprecate them for 5.1 or IMO better just remove them for 5.0 as currently ReFrame is the only EC using this and it is trivial to update.