Poetry is incompatible with unstable-tagged Python builds (Invalid PEP 440 version: '3.Y.Z+')
See original GitHub issueI’v just installed Python3.11 from deadsnakes/nightly.
Poetry can’t use it, because the Python version has a + in it.
Invalid PEP 440 version: '3.11.0+' is all I get 😭
P.S. if the wise men declare that deadsnakes is at fault here, I’ll happily bug dead snakes.
Issue Analytics
- State:
- Created a year ago
- Comments:28 (21 by maintainers)
Top Results From Across the Web
Upgrade poetry 1.2.0 tox.ini error Invalide PEP440 version
It might be a dependency that has Python version 3.8.13+ set as a dependency. So you could comment out all (dev) dependencies, then...
Read more >PEP 621 – Storing project metadata in pyproject.toml
Encourage users to specify core metadata statically for speed, ease of specification, unambiguity, and deterministic consumption by build back-ends; Provide a ...
Read more >poetry-dynamic-versioning - PyPI
This is a Python 3.7+ plugin for Poetry 1.2.0+ and Poetry Core 1.0.0+ to enable dynamic versioning based on tags in your version...
Read more >Invalid PEP 440 version: '0.16.0~ynh1' - YunoHost Forum
A YunoHost package version like: 0.16.0~ynh1 is not Python PEP 440 conform :frowning: and newer version of Poetry will not accept it any ......
Read more >The pyproject.toml file | Documentation | Poetry
Required This should be a valid name as defined by PEP 508. name = "my-package" version The version of the package. Required This...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

My thinking is we should centralize it using a
parse_python_version()variant that encapsulates the stripping of the+so we don’t randomly proliferate it in the codebase and get burned by a future omission. Theparse_python_version()code can just be a preprocessing before we hand it to our regular version parsing code, and can be unit tested; we should also end-to-end test the main usage (inenv.py).Hi, what about something like this? (it works in my local tests in Debian)