python.path with "Python 3.11.0+" is considered to be invalid / gets replaced #1510
Comments
|
I made a simple fix to address the upstream problem. It will be released soon. |
|
I think that I found another place where it chokes on the same problem: |
|
@ssbarnea please provide more information to help address the cause
import packaging
from packaging.markers import default_environment, Marker
print(packaging.__version__) # make sure it is >=22
print(default_environment())
print(Marker('python_full_version >= "3.8.0"').evaluate()) |
|
Here are the below results, which were like I was expecting. The root cause of the bug was to assume that Instead the I mention this because I personally faced a similar bug in another project, which I was able to address by avoiding the use of the free-form string. In other cases where I had to deal with Version parsing, I catched the exception and provide a fallback mechanism. Please note that I would usually just raise a PR for simple bugs like this but I do not yet know the pdm project good-enough to know how to address this correctly, especially as there might be multiple places that might need similar patching for version identification. $ pdm info --env
{
"implementation_name": "cpython",
"implementation_version": "3.11.0",
"os_name": "posix",
"platform_machine": "arm64",
"platform_release": "22.2.0",
"platform_system": "Darwin",
"platform_version": "Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000",
"python_full_version": "3.11.0+",
"platform_python_implementation": "CPython",
"python_version": "3.11",
"sys_platform": "darwin"
}ssbarnea@m1: ~/c/os/mkdocs/mkdocstrings v chore/grammar
$ python
Python 3.11.0+ (heads/3.11:4cd5ea62ac, Oct 25 2022, 18:19:49) [Clang 14.0.0 (clang-1400.0.29.102)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import packaging
>>> from packaging.markers import default_environment, Marker
>>> print(packaging.__version__) # make sure it is >=22
23.0
>>> print(default_environment())
{'implementation_name': 'cpython', 'implementation_version': '3.11.0', 'os_name': 'posix', 'platform_machine': 'arm64', 'platform_release': '22.2.0', 'platform_system': 'Darwin', 'platform_version': 'Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000', 'python_full_version': '3.11.0+', 'platform_python_implementation': 'CPython', 'python_version': '3.11', 'sys_platform': 'darwin'}
>>> print(Marker('python_full_version >= "3.8.0"').evaluate())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/ssbarnea/c/a/r1/v/lib/python3.11/site-packages/packaging/markers.py", line 245, in evaluate
return _evaluate_markers(self._markers, current_environment)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/ssbarnea/c/a/r1/v/lib/python3.11/site-packages/packaging/markers.py", line 151, in _evaluate_markers
groups[-1].append(_eval_op(lhs_value, op, rhs_value))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/ssbarnea/c/a/r1/v/lib/python3.11/site-packages/packaging/markers.py", line 109, in _eval_op
return spec.contains(lhs, prereleases=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/ssbarnea/c/a/r1/v/lib/python3.11/site-packages/packaging/specifiers.py", line 565, in contains
normalized_item = _coerce_version(item)
^^^^^^^^^^^^^^^^^^^^^
File "/Users/ssbarnea/c/a/r1/v/lib/python3.11/site-packages/packaging/specifiers.py", line 36, in _coerce_version
version = Version(version)
^^^^^^^^^^^^^^^^
File "/Users/ssbarnea/c/a/r1/v/lib/python3.11/site-packages/packaging/version.py", line 197, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '3.11.0+' |
So i guess |
|
Definitely that it will not work like expected, you are probably the first person that I see using it in markers instead of the documented https://sourcegraph.com/search?q=context:global+path:setup.cfg+%22python_version+%3C%22&patternType=standard&sm=0&groupBy=repo with uncounted results versus https://sourcegraph.com/search?q=context:global+path:setup.cfg+python_full_version&patternType=standard&sm=0&groupBy=repo which reports only one project using that and event that one also uses python_version at the same time, so is not affected. I do not have the link now, but I do remember reading probably even official docs that version comparison should be made using the already provided version tuple, |
|
@frostming Any more ideas on how to address this issue? Even if the line that you asked me to try does not "work" as expected, it does not raise a tracedump, it just evaluates as false with I am really wondering why pdm really needs to attempt to parse >>> sys.version_info
sys.version_info(major=3, minor=11, micro=0, releaselevel='final', serial=0) |
It is not determined by PDM, if the requirement contains environment markers with |
|
Related to pyenv/pyenv#2598 - how this is dealt with depends. I did not see any place in Python documentation that states that |
|
The marker evaluation behavior indeed is standardized by PEP 508, notably:
and
I think this is clear enough, it doesn't suggest using |
Given
.pdm.toml:and Python compiled from the 3.11 branch (not on a release tag), where
python --versiongives "Python 3.11.0+" pdm will replace the config withpython.path = "/usr/bin/python3.10".This is likely due to frostming/findpython#12, but on top it seems like a configured path should be not changed automatically, and also be used without (too strict) checks.
The text was updated successfully, but these errors were encountered: