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.

Sign up for GitHub

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

Jump to bottom

uv sync gets stuck if the index and lockfile URLs are not reachable and there are dynamic fields in pyproject #8074

Closed
mgab opened this issue Oct 10, 2024 · 2 comments · Fixed by #8083
Closed

uv sync gets stuck if the index and lockfile URLs are not reachable and there are dynamic fields in pyproject #8074

mgab opened this issue Oct 10, 2024 · 2 comments · Fixed by #8083
Assignees
@charliermarsh
Labels
bug Something isn't working

Comments

@mgab
Copy link

mgab commented Oct 10, 2024

Problem description

uv sync gets stuck (I waited for more than 5 minutes before killing it) if:

  • there are dynamic fields in pyproject (I tried with the version)
  • the index URL with highest priority is not reachable (either extra-index-url or index-url, either in ~/.config/uv/uv.toml or in pyproject.toml)
  • the URLs in the lockfile are not reachable

Steps to reproduce:

  • make sure you do not have any index url configured
  • execute uv sync in a directory with this pyproject.toml.txt and this uv.lock.txt files (removing the .txt suffix I had to add so that github allowed me to upload the files)

If you change the url to a responsive one, it will fail with an error because there will be no git repository to get the version from, no any src/test_app package, but that'd be the expected behavior.

Versions

Platform: macOS 14.6.1
uv version: uv 0.4.19 (Homebrew 2024-10-07)

Debug traces

❯ uv sync --verbose
DEBUG uv 0.4.19 (Homebrew 2024-10-07)
DEBUG Found project root: `/Users/username/Code/test`
DEBUG No workspace root found, using project root
DEBUG The virtual environment's Python version satisfies `Python >=3.12`
DEBUG Using request timeout of 30s
DEBUG No static `pyproject.toml` available for: test-app @ file:///Users/username/Code/test (PyprojectToml(DynamicField("version")))
DEBUG Acquired lock for `/Users/username/.cache/uv/sdists-v4/editable/b0b82e1806a4930c`
WARN Failed to read metadata for file: No such file or directory (os error 2)
WARN Failed to read metadata for file: No such file or directory (os error 2)
DEBUG Preparing metadata for: test-app @ file:///Users/username/Code/test
DEBUG Ignoring empty directory
DEBUG Resolving build requirements
DEBUG Solving with installed Python version: 3.12.5
DEBUG Solving with target Python version: >=3.12.5
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG No cache entry for: http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/
DEBUG No cache entry for: http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatch-vcs/
DEBUG Transient request failure for http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/, retrying: error sending request for url (http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/)
  Caused by: client error (Connect)
  Caused by: dns error: failed to lookup address information: nodename nor servname provided, or not known
  Caused by: failed to lookup address information: nodename nor servname provided, or not known
DEBUG Transient request failure for http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatch-vcs/, retrying: error sending request for url (http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatch-vcs/)
  Caused by: client error (Connect)
  Caused by: dns error: failed to lookup address information: nodename nor servname provided, or not known
  Caused by: failed to lookup address information: nodename nor servname provided, or not known
DEBUG Transient request failure for http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/, retrying: error sending request for url (http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/)
  Caused by: client error (Connect)
  Caused by: dns error: failed to lookup address information: nodename nor servname provided, or not known
  Caused by: failed to lookup address information: nodename nor servname provided, or not known
DEBUG Transient request failure for http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatch-vcs/, retrying: error sending request for url (http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatch-vcs/)
  Caused by: client error (Connect)
  Caused by: dns error: failed to lookup address information: nodename nor servname provided, or not known
  Caused by: failed to lookup address information: nodename nor servname provided, or not known
DEBUG Transient request failure for http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/, retrying: error sending request for url (http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/)
  Caused by: client error (Connect)
  Caused by: dns error: failed to lookup address information: nodename nor servname provided, or not known
  Caused by: failed to lookup address information: nodename nor servname provided, or not known
DEBUG Transient request failure for http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatch-vcs/, retrying: error sending request for url (http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatch-vcs/)
  Caused by: client error (Connect)
  Caused by: dns error: failed to lookup address information: nodename nor servname provided, or not known
  Caused by: failed to lookup address information: nodename nor servname provided, or not known
DEBUG Transient request failure for http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/, retrying: error sending request for url (http://nexus.internal.stuart.com:8081/repository/pypi-group/simple/hatchling/)
  Caused by: client error (Connect)
  Caused by: dns error: failed to lookup address information: nodename nor servname provided, or not known
  Caused by: failed to lookup address information: nodename nor servname provided, or not known
DEBUG Released lock at `/Users/username/.cache/uv/sdists-v4/editable/b0b82e1806a4930c/.lock`
DEBUG Ignoring existing lockfile due to missing metadata for: `test-app==0.1.dev1+g85e54b6.d20241010`
DEBUG Starting clean resolution
DEBUG No static `pyproject.toml` available for: test-app @ file:///Users/username/Code/test (PyprojectToml(DynamicField("version")))
DEBUG Acquired lock for `/Users/username.cache/uv/sdists-v4/editable/b0b82e1806a4930c`
WARN Failed to read metadata for file: No such file or directory (os error 2)
WARN Failed to read metadata for file: No such file or directory (os error 2)
DEBUG Preparing metadata for: test-app @ file:///Users/username/Code/test
DEBUG Ignoring empty directory
DEBUG Resolving build requirements
DEBUG Solving with installed Python version: 3.12.5
DEBUG Solving with target Python version: >=3.12.5
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
@mgab mgab mentioned this issue Oct 10, 2024
Open
@charliermarsh
Copy link
Member

I see a few retries there, but we should probably error after the third retry per our limits.

@charliermarsh charliermarsh self-assigned this Oct 10, 2024
@charliermarsh charliermarsh added the bug Something isn't working label Oct 10, 2024
@charliermarsh
Copy link
Member

I see the issue here.

@charliermarsh charliermarsh mentioned this issue Oct 10, 2024
Merged
charliermarsh added a commit that referenced this issue Oct 10, 2024
@charliermarsh
Treat resolver failures as fatal in lockfile validation (#8083)
7bac708 
## Summary

In the routine we use to verify whether the lockfile is up-to-date, we
sometimes have to resolve package metadata. If that resolution step
fails, the resolver is left in a bad state, as various tasks are marked
as pending despite the error. Treating that as a recoverable failure
thus leads to a deadlock.

This PR modifies the errors to be treated as fatal.

I think a more holistic fix here would be to add some kind of guard to
ensure that any tasks that fail are no longer marked as pending (or
enforce this in the type system).

Closes #8074.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@charliermarsh charliermarsh

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Treat resolver failures as fatal in lockfile validation astral-sh/uv
2 participants
@charliermarsh @mgab