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 pip compile fails with extra-index-url #2775

Closed
RobMcH opened this issue Apr 2, 2024 · 5 comments · Fixed by #2815
Closed

UV pip compile fails with extra-index-url #2775

RobMcH opened this issue Apr 2, 2024 · 5 comments · Fixed by #2815
Assignees

Comments

@RobMcH
Copy link

RobMcH commented Apr 2, 2024

I am trying to use uv pip compile as a drop-in replacement for pip-compile and am running into issues with how extra-index-url is handled. A minimal working example would be the following requirements.in

networkx==2.5
torch==2.1.0+cu118

running without extra-index-url will error out as it cannot find torch (as expected):

uv pip compile --generate-hashes  requirements.in -o requirements.txt
  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of torch==2.1.0+cu118 and you require torch==2.1.0+cu118, we can conclude that the requirements are unsatisfiable.

and running with extra-index-url will error out as it seemingly cannot find networkx on the extra-index (it seems not to check the original index?):

uv pip compile --generate-hashes --extra-index-url "https://download.pytorch.org/whl/cu118" requirements.in -o requirements.txt
  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of networkx==2.5 and you require networkx==2.5, we can conclude that the requirements are unsatisfiable.

I am using the latest uv version (0.1.27). This might be related to existing PyTorch issues here, but it seems those are all related to installing PyTorch, rather than creating a requirements.txt using uv pip compile.

@charliermarsh
Copy link
Member

For security purposes, we don’t currently allow packages to be looked up on multiple indexes. You can read more on it here: https://github.com/astral-sh/uv/blob/main/PIP_COMPATIBILITY.md#packages-that-exist-on-multiple-indexes

In this case my guess is that networkx exists on the PyTorch index, but not at that version, so uv can’t find it.

@RobMcH
Copy link
Author

RobMcH commented Apr 2, 2024

Thanks! So until uv supports specifying registries for each package individually, torch is essentially incompatible with uv in certain configurations (when one of the other requirements also lives on the torch registry but not all versions are there)?

@charliermarsh
Copy link
Member

Yeah. There are a few workarounds: you can use direct URLs for the Torch dependencies, and omit the extra index altogether. Or you should be able to use —find-links instead of an extra index, and that would also work around the issue.

I’m considering adding an opt-in flag to allow this though. It’s not a technical limitation, but rather a security limitation.

@charliermarsh charliermarsh self-assigned this Apr 2, 2024
charliermarsh added a commit that referenced this issue Apr 3, 2024
)

## Summary

This partially revives #2135 (with
some modifications) to enable users to opt-in to looking for packages
across multiple indexes.

The behavior is such that, in version selection, we take _any_
compatible version from a "higher-priority" index over the compatible
versions of a "lower-priority" index, even if that means we might accept
an "older" version.

Closes #2775.
@korhojoa
Copy link

uv.toml doesn't seem to respect/support this:

venv/bin/python -m uv pip install --verbose --upgrade pip-tools
error: Failed to parse `uv.toml`
  Caused by: TOML parse error at line 2, column 18
  |
2 | index-strategy = "unsafe-any-match"
  |                  ^^^^^^^^^^^^^^^^^^
unknown variant `unsafe-any-match`, expected one of `first-index`, `unsafe-first-match`, `unsafe-best-match`

@charliermarsh
Copy link
Member

@korhojoa - you want unsafe-first-match -- unsafe-any-match is a deprecated alias. I will add backwards-compatible support for it though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants