Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infinite loop when resolving deps (normalization problem) #5474

Closed
2 tasks done
karlb opened this issue Apr 21, 2022 · 2 comments · Fixed by python-poetry/poetry-core#328
Closed
2 tasks done

Infinite loop when resolving deps (normalization problem) #5474

karlb opened this issue Apr 21, 2022 · 2 comments · Fixed by python-poetry/poetry-core#328
Labels
kind/bug Something isn't working as expected

Comments

@karlb
Copy link

karlb commented Apr 21, 2022

Issue

When running poetry update, the Resolving dependencies... step is stuck in what seems to be an infinite loop. It runs for a long time (>1000s) until I am force to kill it, because it starts to use excessive amounts of memory (>8GB).

The problem only happens when dependencies are involved where the declared dependency name differs from the PyPI package name in ways allowed by the package name normalization. In the gist, the problematic dependencies are zope-interface (zope.interface on PyPI) and zope-event (zope.event on PyPI). These are transitive dependencies of the "bug" project included via the raiden dependency.

This seems to be related to #3365 and #3200 and a potential duplicate of these. However, the case is slightly different, since the problematic dependencies are not declared in the package managed by poetry, but in a dependency (which is not created using poetry). Due to this, I don't see a way to work around this by changing the pyproject.toml as done in #3132 (comment).

@karlb karlb added kind/bug Something isn't working as expected status/triage This issue needs to be triaged labels Apr 21, 2022
@kenahoo
Copy link

kenahoo commented Apr 22, 2022

I'm not sure if what I'm seeing is the same thing, but it certainly could be. I turned on verbose mode with -vv and I can see that it's downloading and checking many many pre-release versions of a dependency (because it is declared with allow-prereleases = true), which I'm willing to live with, but here's the kicker:

It gets slower and slower with each version it's checking. There are a couple hundred pre-releases it's checking. When it started checking them it was easily doing 20 versions per second or more; after running for a while it's taking at least 5 seconds per version, and is getting slower and slower. The behavior seems quadratic in the size of the number of versions it's checking (just a guess).

@mkniewallner mkniewallner removed the status/triage This issue needs to be triaged label Jun 11, 2022
Copy link

github-actions bot commented Mar 1, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Something isn't working as expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants