poetry: Poetry is incompatible with unstable-tagged Python builds (Invalid PEP 440 version: '3.Y.Z+')

I think it’s obvious that deadsnakes in general is broken with Poetry as both 3.11 and 3.10 are GA versions.

There is no need to comment with a ‘me too’ here – this will be true for any non-release build of Python, so 3.x-dev will be universally affected.

Maybe a ‘me too’ comment is not that useful from a development point of view, but it’ is a way to express that this issue is affecting many users.

I understand that fixing this will be invasive/painful, but I can’t agree that this is so low priority as it seems to be for you: Poetry is a development tool and IMHO it should be expected that users of Poetry use whatsoever Python version.

A quick note on Debian, too. If you want/need an up to date system, 90% of the time you can’t use Debian stable: you want testing, and you’ll probably install selected packages from experimental and/or PPAs. This is physiologically due to the “release when ready” Debian policy. I think the vast majority of Debian users are running testing most of the time (except when just released, obviously).

“Me too” is wholly unproductive – GitHub has 👍 for that, which both is surfaced in the UI as a voting method, and avoids sending unnecessary notifications. Browbeating the volunteer maintainers of a project is not the way to get an issue prioritized; typically the way to do that is by sending a patch.

#7462 is under review as one possible approach; if you want to see things move faster I would suggest sending your own PR with a combination of the feedback from https://github.com/python-poetry/poetry/issues/6925#issuecomment-1333245172 and https://github.com/python-poetry/poetry/pull/7462#discussion_r1096542675 incorporated.

I’m sorry that you feel Poetry is defective for your needs because of this issue; Poetry is not unique here, and as you can see from the linked issues, this is something of an ecosystem-wide problem. Regrettably, there is not infinite time in the day, and no one is paid to work on Poetry or sells you any sort of support. The best we can do is collaborate to improve the tool, and make things as actionable as possible so that maintainer time can be used as efficiently as possible.

Not sure whether it brings anything useful to the table, but the Python 3.12.0a2 ‘release’ (installed using pyenv) also reports its version as 3.12.0a2+ and thus fails to work with Poetry.

Hi, what about something like this? (it works in my local tests in Debian)

Index: src/poetry/utils/env.py
===================================================================
--- src/poetry/utils/env.py	2022-11-30 20:30:11.425524136 -0300
+++ src/poetry/utils/env.py	2022-11-30 20:30:31.829803450 -0300
@@ -1618,7 +1618,7 @@
             "platform_release": platform.release(),
             "platform_system": platform.system(),
             "platform_version": platform.version(),
-            "python_full_version": platform.python_version(),
+            "python_full_version": platform.python_version().rstrip("+"),
             "platform_python_implementation": platform.python_implementation(),
             "python_version": ".".join(platform.python_version().split(".")[:2]),
             "sys_platform": sys.platform,

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. The parse_python_version() code can just be a preprocessing step 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 (in env.py).

um, it obviously is using nightly builds. You can tell by the version number!

Just checked and you are right. It is not using the actual final but some other commit from the 3.11 branch. Sorry about assuming it was, the packages from debian usually use official released tarballs.

probably “testing and unstable” is the clue

Not really. The name is misleading, but testing is just an alias to the codename that will become the next stable version, and unstable is where packages get uploaded and automatically get migrated to the testing one if not issues are found. The debian team doesn’t usually upload nightly versions to any of those repositories (there’s a experimental repository for that there), and those packages will be the ones in the final stable release (just as they are, no repacking or recompiling) as long as no critical issues are found and no new versions are released and packaged.

Indeed, I am not worried about that case as much:

• python3.11 is explicitly experimental in unstable/testing; Debian does not ship Python versions in parallel under normal circumstances
• Unstable/testing are moving targets and not reasonable environments for 95% of users; those who are using them are theoretically equipped to understand and mitigate this kind of transient issue
• Debian Python packaging is always idiosyncratic and bordering on broken; there is a maintainer who is invested in papering over decisions made by Debian, but he has had little time lately and no one else is invested in it

to be fair it is the very first sentence of the very opening of this thread

Sorry for the noise to poetry maintainers, but as a general notice for pyenv users finding this issue ( @magniff @yssource @jshwi ): a pyenv python version X.Y-dev means development, and will have the + suffix. However, as the readme notes, most commands will auto-resolve to the latest version.

So if you run pyenv install 3.8, pyenv will install the latest 3.8.z (no +), and if you run pyenv global 3.8, pyenv will set the latest installed 3.8.z as your global. As *-dev will always be the latest if you have it installed, just make sure not to install a -dev release, and you should be good.

This happens for me if run poetry install without an existing environment if i installed poetry using curl -sSL https://install.python-poetry.org | python3 - --force while under pyenv global 3.x-dev

If I use poetry env use 3.y this works, but as long as 3.y-dev is not installed under pyenv

I have to be in a specific version, patch included, e.g. 3.8.13 when running curl -sSL https://install.python-poetry.org | python3 - --force for my for poetry to work by default, without needing to use poetry env use 3.<some_other_minor_version> as long as 3.<some_other_minor_version>-dev is not installed

The workaround for me is

• pyenv install 3.8.13
• pyenv uninstall 3.8-dev
• pyenv global 3.8.13
• curl -sSL https://install.python-poetry.org | python3 - --force

I am on macos

Debian Python person here:

python3.11 is explicitly experimental in unstable/testing; Debian does not ship Python versions in parallel under normal circumstances

It’s in the process of becoming supported. Hopefully for the next stable release, but that depends on how much of the world works with it, and whether we can fix the rest in time.

Unstable/testing are moving targets and not reasonable environments for 95% of users; those who are using them are theoretically equipped to understand and mitigate this kind of transient issue Debian Python packaging is always idiosyncratic and bordering on broken; there is a maintainer who is invested in papering over decisions made by Debian, but he has had little time lately and no one else is invested in it

I wouldn’t really agree with either of these sentiments. But bugs aren’t the place to litigate that. I really don’t think Debian did anything wrong here. Poetry didn’t expect to see a + in a Python version, but they are now something to be expected, since 3.11. That’s about the extent of the issue, here.

the regular 3.10 build is not ‘broken’ and I imagine neither is 3.11, rather folk are choosing to use nightly builds.

I get my 3.10 from deadsnakes myself, and the versioning is completely normal:

$ cat /etc/apt/sources.list.d/deadsnakes-ubuntu-ppa-focal.list
deb http://ppa.launchpad.net/deadsnakes/ppa/ubuntu focal main
# deb-src http://ppa.launchpad.net/deadsnakes/ppa/ubuntu focal main

$ python3.10 --version
Python 3.10.8

$ python3.10 -c 'import platform ; print(platform.python_version())'
3.10.8

that still leaves poetry confused by version numbers from nightly builds: but nearly no-one should have any reason to use those, certainly for pythons 3.10 and 3.11