astral-sh / uv

An extremely fast Python package and project manager, written in Rust.
https://docs.astral.sh/uv
Apache License 2.0
20.28k stars 602 forks source link

uv add generating unstable environments when used with local version identifiers #7461

Open itrase opened 1 day ago

itrase commented 1 day ago

On uv version 0.4.10

To reproduce: mkdir project_a cd project_a uv init uv add torch==2.4.1+cu124 --index-url https://download.pytorch.org/whl/cu124 uv add numpy

The resulting environment technically works (torch is available for import and uses the correct version of CUDA), but trying to add numpy (or any other package) will give the following error:

  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of torch==2.4.1+cu124 and your project depends on torch==2.4.1+cu124, we can conclude that
      your project's requirements are unsatisfiable.
  help: If this is intentional, run `uv add --frozen` to skip the lock and sync steps.

My expectation with uv add is that it is intended to result in a reproducible environment, but it doesn't feel like it is the case here. I know that there is significant weirdness around local version identifiers, so perhaps this is intended behavior - but if so, having uv emit a warning would be good.

We can solve this by adding the following to the pyproject.toml:

[tool.uv]
extra-index-url = [
    "https://download.pytorch.org/whl/cu124",
]

This allows us to continue to add packages as normal. However, if I then initialize another project and try to add project_a, things break again:

mkdir project_b cd project_b uv init uv add ../project_a --editable

We get the same error:

  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of torch==2.4.1+cu124 and project-a==0.1.0 depends on torch==2.4.1+cu124, we can conclude
      that project-a==0.1.0 cannot be used.
      And because only project-a==0.1.0 is available and your project depends on project-a, we can conclude that your
      project's requirements are unsatisfiable.
  help: If this is intentional, run `uv add --frozen` to skip the lock and sync steps.

Once again, we can solve this by adding the extra-index-url to project_b's pyproject.toml, but my expectation is that the extra index should be inherited automatically.

I believe a similar problem exists for things like torch-scatter, which want to use find-links to be installed: uv add torch_scatter -f https://data.pyg.org/whl/torch-2.4.0+cu124.html adding a find-links section to the [tool.uv] allows it to proceed, but results in all downstream projects needing that line as well.

charliermarsh commented 1 day ago

I think uv add should add the index, and we're going to do that as part of some larger changes to how indexes are handled. (I don't think that project_b should implicitly use the PyTorch index, but this will become easier to get right when we make the aforementioned changes.)