poetry-core 1.0.5 fails to find installation candidate

[JacobHenner]

• I am on the latest Poetry version.

• I have searched the issues of this repo and believe that this is not a duplicate.

• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: RHEL 7, CentOS 7, and others

• Poetry version: 1.1.4, 1.1.8, 1.1.9

Issue

Upon upgrading to poetry 1.1.9, I observed that I could no longer install a specific package in some of my projects. The package exists in two places - pypi.org, and an internal repo (running Nexus). In both places, the package is identical (i.e. same hash). Both pypi.org (as a default) and my internal repo (via configuration in pyproject.toml) is available for these projects.

When I try to install, I get the following:

  Unable to find installation candidates for kerberos (1.3.1)

  at ~/.local/pipx/venvs/poetry/lib/python3.8/site-packages/poetry/installation/chooser.py:72 in choose_for
       68│ 
       69│             links.append(link)
       70│ 
       71│         if not links:
    →  72│             raise RuntimeError(
       73│                 "Unable to find installation candidates for {}".format(package)
       74│             )
       75│ 
       76│         # Get the best link

The relevant parts of poetry.lock are:

[[package]]
name = "kerberos"
version = "1.3.1"
description = "Kerberos high-level interface"
category = "main"
optional = false
python-versions = "*"

[package.source]
type = "legacy"
url = "<url-to-internal-repo>"
reference = "<name-of-internal-repo>"

and

    [
        {file = "kerberos-1.3.1-cp38-cp38-macosx_10_15_x86_64.whl", hash = "md5:813b4beec4a4641d7772346d2b6485d8"},
        {file = "kerberos-1.3.1-cp39-cp39-macosx_10_9_x86_64.whl", hash = "md5:255c2409de0795669030bbc1e78ac462"},
    ]

(interestingly, in that second section, the two entries are not relevant to my platform/python version. Other entries exist on both pypi.org and my internal repo)

After noticing these failures with 1.1.9, I downgraded to 1.1.8, and eventually back to the last-known-good 1.1.4. The problem continued to occur. Once I downgraded poetry-core from 1.0.5 to 1.0.4, the issue resolved (with both poetry 1.1.4 and 1.1.9).

This looks vaguely familiar to other issues like #3456, and I also encountered something that looks like #4523 today while debugging, but I think those issues are distinct from this specific problem.

[iNerV]

install from gemfury not working, gemfury has only md5 hashes.

how it hotfix?

[remram44]

Duplicate of #4523?

[JacobHenner]

Duplicate of #4523?

Not sure about that - the error message is distinct. It could be related, however.

[Asciotti]

I'd like to add that members of my team have had the same exact issue. We had numerous accounts of the same exact error message on recently (within the last ~1-2 weeeks) failing CI builds. The required packages were not being install (so cp3X for manylinux). These errors seem to coincide with poetry-core and poetry new releases.

What is strange is that our lock files actually had been broken for months. Our hypthesis is that the recent introduction of the newer poetry versions added some error checking (changelog from 1.1.9+10 that was released ~12 days ago) that now were causing failures on our broken lock files. Or, the introduction of 1.0.5 from poetry core (link) is causing the issues. We haven't disentangled it entirely yet since my machine never had any issues.

We've also tried the upgrading/downgrading of poetry and python across 1.1.{4,6,8,9,10} and 3.7 -> 3.8 with no fix to those machine's who were consistently generating incorrect lock files. We also tried to remove every trace of poetry from a user's machine and reinstall poetry via the curl ... recommended installation method - no dice.

[remram44]

@Asciotti are you also using md5 hashes in your poetry.lock? Did you try recreating the lock files?

[Asciotti]

We had no issues with md5 hashes and they aren't in any of our lock files (or aren't causing issues so didn't notice). The various wheels are just missing.

We tried recreating the lock files numerous times across multiple machines + poetry versions + python versions + os's. The user's machines who were consistently creating malformed lock files continued to do that. We tried this with a minimal reproducible pyproject.toml as well (just specified python and the singular package that kept failing). The one thing we didn't experiment with was poetry-core.

I have to go collect the user's info to get debugging environment - as I said, my machine hasn't been affected.

[Asciotti]

Here is one of our data points, we just tried downgrading poetry-core with no resolution. Here is some info of one of our user's env and the results.

OS: macOS 10.15.17

poetry debug:

Poetry
Version: 1.1.10
Python:  3.8.6

Virtualenv
Python:         3.8.6
Implementation: CPython
Path:           /Users/<user>/Library/Caches/pypoetry/virtualenvs/<cache-env>
Valid:          True

System
Platform: darwin
OS:       posix
Python:   /Users/<user>/.pyenv/versions/3.8.6

pyproject.toml:

[tool]
[tool.poetry]
name = "test"
version = "0.0.1"
description = "desc"
authors = []

[tool.poetry.dependencies]
python = "~3.8"
pyarrow = "^5.0.0"

[tool.poetry.dev-dependencies]

[[tool.poetry.source]]
name = "pypi-<company>"
url = "<internal-pypi>"
default = true

[build-system]
requires = ["poetry-core>=1.0.0,<1.0.5"] <- notice the pinned below 1.0.5
build-backend = "poetry.core.masonry.api"

poetry.lock:

...
pyarrow = [
    {file = "pyarrow-5.0.0-cp36-cp36m-manylinux2014_x86_64.whl", hash = "sha256:99c8b0f7e2ce2541dd4c0c0101d9944bb8e592ae3295fe7a2f290ab99222666d"},
]

Notice we are still missing cp38 within the lock file, despite that being the python version set.

Will try to downgrade poetry to 1.1.8|9 and redo the sequence.

[tmehlinger]

We just ran into this on my team.

For us, the problem was one of our teammates had an older version of Poetry installed (1.0.5) and generated a lockfile. When we tried to install dependencies in a Docker image with Poetry 1.1.8, it failed with the stack trace given in the original report above. Regenerating the lock file with 1.1.8 resolved the problem.

[neersighted]

Closing this as there have been no reports recently of anything related, and there was not a reproduction in this issue. If you're running into something similar, please open a new issue after troubleshooting as much as you can (and consider reaching on Discord if you need help troubleshooting).

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.