-
Notifications
You must be signed in to change notification settings - Fork 863
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 does not resolve dependencies with multiple indexes and extra
markers as expected
#9086
Comments
That's correct. We don't support this right now. You should follow the conflicting extras work. |
See: #8976 |
Specifically, we don't allow you to ask for conflicting versions of a package based on the presence of an extra. In the (near) future, you can mark extras as mutually incompatible, which will let you do what you want here without trouble. |
The relevant issue to follow is actually here: #6981. I'm gonna merge into that. |
Man, coming back here the next day to see both the issues you linked have been merged is so cool. You guys rock! |
This still doesn't seem to be working fully. Using 0.5.2 I still only get one index queried. I've specified:
And now it fails to resolve dependencies because it can't find |
@Karlinator -- I think there's specific work that needs to happen atop #6981 to respect extras in |
I have the exact same use case as @Karlinator, which is why I was quite excited about the new features for conflicting extras/groups. I would greatly appreciate it if you could make this work @charliermarsh --then my team could finally switch to uv! 😊 |
Totally hear you. We definitely want to support this use-case. |
This now works in v0.5.3: [project]
name = "project"
version = "0.1.0"
requires-python = ">=3.12.0"
dependencies = []
[project.optional-dependencies]
cpu = [
"torch>=2.5.1",
"torchvision>=0.20.1",
]
cu124 = [
"torch>=2.5.1",
"torchvision>=0.20.1",
]
[tool.uv]
conflicts = [
[
{ extra = "cpu" },
{ extra = "cu124" },
],
]
[tool.uv.sources]
torch = [
{ index = "pytorch-cpu", extra = "cpu", marker = "platform_system != 'Darwin'" },
{ index = "pytorch-cu124", extra = "cu124" },
]
torchvision = [
{ index = "pytorch-cpu", extra = "cpu", marker = "platform_system != 'Darwin'" },
{ index = "pytorch-cu124", extra = "cu124" },
]
[[tool.uv.index]]
name = "pytorch-cpu"
url = "https://download.pytorch.org/whl/cpu"
explicit = true
[[tool.uv.index]]
name = "pytorch-cu124"
url = "https://download.pytorch.org/whl/cu124"
explicit = true Docs on PyTorch here. |
uv 0.5.1, python 3.13, Fedora 41.
I'm trying to set up a project such that I can install it in three different ways:
I've tried roughly 5000 different things without success. Here's where I'm at now:
However, the lockfile seems to have not considered the split on
extra
here, and only resolves either the cpu variant or the cuda variant (in this exact axample it's the cpu variant, but messing around with it a little you can get the cuda variant instead). So doinguv sync --group torch --extra cuda
anduv sync --group torch
gives the exact same result.The first part of the lockfile looks correct (tying the specifier and index to the marker), but then it only resolves one version of torch, and that's 2.5.1+cpu with cpu wheels and missing the cuda dependencies.
Looking at the output of
uv -v lock
, it only looks for a compatible version of torch once, and it finds the cpu version only. It doesn't split on the "extra" marker to look in the separate pinned indexes.I've also tried a variety of extras-based approaches. Commonly, these fail to resolve because even with the sources spec uv goes to pypi to find the metadata, or they end up in the same sitation as above that it just always resolves one or the other.
Is there some way I'm supposed to do this that I haven't found, or is this not fully supported?
I know that this is pytorch being very extra, and that I can get around this by doing
uv pip install torch --index-url="https://downloads.pytorch.org/whl/cpu
and stuff, but that loses out on the benefits of the uv lockfile and all that.The text was updated successfully, but these errors were encountered: