Installing packages from multiple indexes fails if the desired versions are not found from the first index where the package is available. #2205
Comments
korhojoa
changed the title
|
Hi! This has been discussed a lot already e.g.
I would recommend reading the summary in #2083 which explains our current behavior. |
|
Yes, I understand that similar things have been discussed, and the reproduction is a simple one that's very similar. Those issues are kind of outdated now that the preference for This example was supposed to be a minimal reproducible example. The full issue is that if it is necessary to use vendor or third-party indexes to resolve packages, the summary doesn't really help. If you have more than a few packages and more than one index, the chance for the requirements to become unsolvable becomes quite high. #2083 (comment) does not help if there is a package which has local versioning (like torch in this case, as it exists in both) Is there an issue kept open (or documentation somewhere) with a stance on if this use-case would be supported? I would love to switch to uv but as I need to use a handful of indexes and they do have packages which overlap, it doesn't really function as desired. |
|
I think #171 is the issue with the most discussion. The issue started with an idea around pinning specific packages to a specific index, but the discussion kind of spirals out to the more general problem of how pip deals with multiple indexes. In particular, there are security concerns regarding dependency confusion with how pip operates. I think the longer term vision is that we hope to address these sorts of use cases in higher level project management features that will hopefully give one a lot more control over which registries are used. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
It seems like this is the issue we are interested in to find a solution for after debugging my original issue. We have a couple of different indexes where we store dev versions for packages. This means the same package can be in multiple different indexes, but depending on the version it may come from different indexes. Currently we just use pip by adding all our indexes as extra-index-urls, and all our internal dependencies have explicit versions, so there is no fear of getting packages from the wrong index. This is not possible with uv currently, because if we request a dev version, the resolution stops at the first index where the package has any versions, even if it's invalid or doesn't match the request. In my idea if uv were to look for resolutions in the indexes in a specific order, and only stop if it finds a valid version that satisfies the request that would solve many pip incompatibilities. |
|
I'm going to close in favor of #171 and other issues. |
This is on uv 0.1.14.
Probably the easiest way to reproduce is to run
pip-compile --extra-index-url=https://download.pytorch.org/whl/cpu requirements.inwith a requirements.in file that looks like this:
This gets you:
Which doesn't work, because pytorch has a certifi package in their index with a version of 2022.12.7.
Pip handles this okay.
I understand that this is desired behavior for uv, based on #2135
However, I do wish there was a way to let this functionality stay, as I'm going to assume I'm not unique in wanting to use eg. corporate or vendor indexes, which may have versions of packages which are outdated.
Curiously, the package that is reported to be unavailable seems to vary.
The text was updated successfully, but these errors were encountered: