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

uv lock: regression in handling local version identifiers #5220

Closed
ewianda opened this issue Jul 19, 2024 · 1 comment · Fixed by #5232
Closed

uv lock: regression in handling local version identifiers #5220

ewianda opened this issue Jul 19, 2024 · 1 comment · Fixed by #5232
Assignees
Labels
bug Something isn't working lock Related to universal resolution and locking

Comments

@ewianda
Copy link

ewianda commented Jul 19, 2024

$ cat pyproject.toml 
[project]
name = "test"
version = "0.1.0"
description = "test"
dependencies = [
  "sglang[srt]==0.1.19 ;sys_platform == 'linux'",
  "torch==2.3.0+cu118 ;sys_platform == 'linux'",
]
$ uv --version
uv 0.2.25
$ uv lock --extra-index-url https://download.pytorch.org/whl/cu118 --index-strategy=unsafe-first-match 
warning: `uv lock` is experimental and may change without warning.
warning: No `requires-python` field found in the workspace. Defaulting to `>=3.11`.
Resolved 127 packages in 1.14s
$ rm uv.lock 
$ uv self update 
info: Checking for updates...
success: Upgraded `uv` to v0.2.26! https://github.com/astral-sh/uv/releases/tag/0.2.26
$ uv lock --extra-index-url https://download.pytorch.org/whl/cu118 --index-strategy=unsafe-first-match 
warning: `uv lock` is experimental and may change without warning.
warning: No `requires-python` field found in the workspace. Defaulting to `>=3.11`.
  × No solution found when resolving dependencies:
  ╰─▶ Because vllm==0.5.1 depends on torch==2.3.0 and sglang[srt]==0.1.19 depends on vllm==0.5.1, we can conclude that sglang[srt]==0.1.19 and torch{sys_platform == 'linux'}==2.3.0+cu118 are
      incompatible.
      And because test==0.1.0 depends on sglang[srt]==0.1.19 and torch{sys_platform == 'linux'}==2.3.0+cu118, we can conclude that test==0.1.0 cannot be used.
      And because only test==0.1.0 is available and you require test, we can conclude that the requirements are unsatisfiable.
@zanieb zanieb added bug Something isn't working lock Related to universal resolution and locking labels Jul 19, 2024
@charliermarsh
Copy link
Member

Presumedly #5104. @ibraheemdev, can you take a look?

zanieb pushed a commit that referenced this issue Jul 19, 2024
## Summary

This fixes a few bugs introduced by
#5104. I previously thought we could
track conflicting locals the same way we track conflicting URLs in
forks, but it turns out that ends up being very tricky. URL forks work
because we prioritize directly URL requirements. We can't prioritize
locals in the same way without conflicting with the URL prioritization
(this may be possible but it's not trivial), so we run into issues where
a correct resolution depends on the order in which dependencies are
traversed.

Instead, we track local versions across all forks in `Locals`. When
applying a local version, we apply all locals with markers that
intersect with the current fork. This way we end up applying some local
versions without creating a fork. For example, given:
```
// pyproject.toml
dependencies = [
    "torch==2.0.0+cu118 ; platform_machine == 'x86_64'",
]

// requirements.in
torch==2.0.0
.
```

We choose `2.0.0+cu118` in all cases. However, if a disjoint fork is
created based on local versions, the resolver will choose the most
compatible local when it narrows to a specific fork. Thus we correctly
respect local versions when forking:
```
// pyproject.toml
dependencies = [
    "torch==2.0.0+cu118 ; platform_machine == 'x86_64'",
    "torch==2.0.0+cpu ; platform_machine != 'x86_64'"
]

// requirements.in
torch==2.0.0
.
``` 

We should also be able to use a similar strategy for
#5150.

## Test Plan

This fixes #5220 locally for me,
as well as a few other bugs that were not reported yet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working lock Related to universal resolution and locking
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants