InvalidPyVersion raised when trying to add a coverage dependency
#1111
Labels
🐛 bug
Something isn't working
Comments
|
We also started seeing these errors today in our CI jobs. I can't tell yet which project it is from though 🤔 From 621 metadata it sounds like prerelease versions should be valid. |
|
Ours was also due to coverage 6.4.1 which now specifies in setup.py: extras_require={
# Enable pyproject.toml support.
'toml': ['tomli; python_full_version<="3.11.0a6"'],
},This was done do resolve nedbat/coveragepy#1390 |
Hnasar
pushed a commit
to Hnasar/pdm
that referenced
this issue
Jun 2, 2022
Recently, coverage 6.4.1 listed its requirements with an alpha version of
python and this broke PDM's version parsing:
extras_require={
'toml': ['tomli; python_full_version<="3.11.0a6"'],
},
Prerelease `requires-python` versions *are* valid, per these specifications:
* https://peps.python.org/pep-0440/
* https://peps.python.org/pep-0621/#requires-python
* https://packaging.python.org/en/latest/specifications/core-metadata/#requires-python
Therefore this commit adds missing parsing support for `{a|b|rc}[N]`
pre-release specifiers which are used by python language releases:
* https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work
This bug meant that projects that directly or indirectly depended on coverage
were unable to update pdm.lock using commands like `update` `add` `lock` and
`install` because `pdm.models.versions.Version` would raise:
pdm.exceptions.InvalidPyVersion: 3.11.0a6: Prereleases or postreleases are not supported for python version specifers.
Until this is fixed, projects can workaround this by depending on:
"coverage<6.4",
"coverage[toml]<6.4",
Fixes pdm-project#1111
|
I added a pull request which fixes the issue. Until its merged, as a workaround, you can add to |
Hnasar
pushed a commit
to Hnasar/pdm
that referenced
this issue
Jun 3, 2022
Recently, coverage 6.4.1 listed its requirements with an alpha version of
python and this broke PDM's version parsing:
extras_require={
'toml': ['tomli; python_full_version<="3.11.0a6"'],
},
Prerelease `requires-python` versions *are* valid, per these specifications:
* https://peps.python.org/pep-0440/
* https://peps.python.org/pep-0621/#requires-python
* https://packaging.python.org/en/latest/specifications/core-metadata/#requires-python
Therefore this commit adds missing parsing support for `{a|b|rc}[N]`
pre-release specifiers which are used by python language releases:
* https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work
This bug meant that projects that directly or indirectly depended on coverage
were unable to update pdm.lock using commands like `update` `add` `lock` and
`install` because `pdm.models.versions.Version` would raise:
pdm.exceptions.InvalidPyVersion: 3.11.0a6: Prereleases or postreleases are not supported for python version specifers.
Until this is fixed, projects can workaround this by depending on:
"coverage<6.4",
"coverage[toml]<6.4",
Fixes pdm-project#1111
Hnasar
pushed a commit
to Hnasar/pdm
that referenced
this issue
Jun 3, 2022
Recently, coverage 6.4.1 listed its requirements with an alpha version of
python and this broke PDM's version parsing:
extras_require={
'toml': ['tomli; python_full_version<="3.11.0a6"'],
},
Prerelease `requires-python` versions *are* valid, per these specifications:
* https://peps.python.org/pep-0440/
* https://peps.python.org/pep-0621/#requires-python
* https://packaging.python.org/en/latest/specifications/core-metadata/#requires-python
Therefore this commit adds missing parsing support for `{a|b|rc}[N]`
pre-release specifiers which are used by python language releases:
* https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work
This bug meant that projects that directly or indirectly depended on coverage
were unable to update pdm.lock using commands like `update` `add` `lock` and
`install` because `pdm.models.versions.Version` would raise:
pdm.exceptions.InvalidPyVersion: 3.11.0a6: Prereleases or postreleases are not supported for python version specifers.
Until this is fixed, projects can workaround this by depending on:
"coverage<6.4",
"coverage[toml]<6.4",
Fixes pdm-project#1111
frostming
pushed a commit
that referenced
this issue
Jun 3, 2022
…1112) * Fix crash if dependencies have prerelease requires-python versions Recently, coverage 6.4.1 listed its requirements with an alpha version of python and this broke PDM's version parsing: extras_require={ 'toml': ['tomli; python_full_version<="3.11.0a6"'], }, Prerelease `requires-python` versions *are* valid, per these specifications: * https://peps.python.org/pep-0440/ * https://peps.python.org/pep-0621/#requires-python * https://packaging.python.org/en/latest/specifications/core-metadata/#requires-python Therefore this commit adds missing parsing support for `{a|b|rc}[N]` pre-release specifiers which are used by python language releases: * https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work This bug meant that projects that directly or indirectly depended on coverage were unable to update pdm.lock using commands like `update` `add` `lock` and `install` because `pdm.models.versions.Version` would raise: pdm.exceptions.InvalidPyVersion: 3.11.0a6: Prereleases or postreleases are not supported for python version specifers. Until this is fixed, projects can workaround this by depending on: "coverage<6.4", "coverage[toml]<6.4", Fixes #1111 * Remove workaround for pre-release python in global environment Since prereleases are now supported in python specifiers (in the previous commit), we can remove the workaround (from commit 8e72609 for #932) that converted a python prerelease version to a specifier range. Co-authored-by: Hashem Nasarat <hnasarat@beta.team>
ChrisSanderser
added a commit
to ChrisSanderser/pd-ms
that referenced
this issue
Jul 15, 2022
…1112)
* Fix crash if dependencies have prerelease requires-python versions
Recently, coverage 6.4.1 listed its requirements with an alpha version of
python and this broke PDM's version parsing:
extras_require={
'toml': ['tomli; python_full_version<="3.11.0a6"'],
},
Prerelease `requires-python` versions *are* valid, per these specifications:
* https://peps.python.org/pep-0440/
* https://peps.python.org/pep-0621/#requires-python
* https://packaging.python.org/en/latest/specifications/core-metadata/#requires-python
Therefore this commit adds missing parsing support for `{a|b|rc}[N]`
pre-release specifiers which are used by python language releases:
* https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work
This bug meant that projects that directly or indirectly depended on coverage
were unable to update pdm.lock using commands like `update` `add` `lock` and
`install` because `pdm.models.versions.Version` would raise:
pdm.exceptions.InvalidPyVersion: 3.11.0a6: Prereleases or postreleases are not supported for python version specifers.
Until this is fixed, projects can workaround this by depending on:
"coverage<6.4",
"coverage[toml]<6.4",
Fixes pdm-project/pdm#1111
* Remove workaround for pre-release python in global environment
Since prereleases are now supported in python specifiers (in the
previous commit), we can remove the workaround (from commit 8e7260968ac
for #932) that converted a python prerelease version to a specifier
range.
Co-authored-by: Hashem Nasarat <hnasarat@beta.team>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
pdm add "coverage==6.4.1"
Actual behavior
InvalidPyVersion raised
Expected behavior
The dependency was successfully added without errors
Environment Information
PDM version: 1.15.0 Python Interpreter: /usr/bin/python3 (3.10) Project Root: /home/user/.src/project Project Packages: /home/user/.src/project/__pypackages__/3.10 { "implementation_name": "cpython", "implementation_version": "3.10.4", "os_name": "posix", "platform_machine": "x86_64", "platform_release": "5.17.9-1-MANJARO", "platform_system": "Linux", "platform_version": "#1 SMP PREEMPT Wed May 18 09:20:53 UTC 2022", "python_full_version": "3.10.4", "platform_python_implementation": "CPython", "python_version": "3.10", "sys_platform": "linux" }The text was updated successfully, but these errors were encountered: