Improve display of available package ranges #6118

zanieb · 2024-08-15T16:03:13Z

Includes the changes from #6071 but takes them way further.

When we have the set of available versions for a package, we can do a much better job displaying an error.

For example:

❯ uv add 'httpx>999,<9999'
  × No solution found when resolving dependencies:
  ╰─▶ Because only the following versions of httpx are available:
          httpx<=999
          httpx>=9999
      and example==0.1.0 depends on httpx>999,<9999, we can conclude that example==0.1.0 cannot be used.
      And because only example==0.1.0 is available and you require example, we can conclude that the requirements are unsatisfiable.

The resolver has demonstrated that the requested range cannot be used because there are only versions in ranges outside the requested range. However, the display of the range of available versions is pretty bad! We say there are versions of httpx available in ranges that definitely have no versions available.

With this pull request, the error becomes:

❯ uv add 'httpx>999,<9999'
  × No solution found when resolving dependencies:
  ╰─▶ Because only httpx<=1.0.0b0 is available and example depends on httpx>999,<9999, we can conclude that example's
      requirements are unsatisfiable.
      And because your workspace requires example, we can conclude that your workspace's requirements are unsatisfiable.

We achieve this by:

Dropping ranges disjoint with the range of available versions, e.g., this removes httpx>=9999
Replacing ranges that capture the entire range of available versions with the smaller range, e.g., this replaces httpx<=999 with <=1.0.0b0.

Note that when we perform (2), we may include an additional bound that is not relevant, e.g., we include the lower bound of >=0.6.7. This is a bit extraneous, but I don't think it's confusing. We can consider some advanced logic to avoid that later. (edit: I did this, it wasn't hard)

We also improve error messages when there is only one version available by showing that version instead of a range.

crates/uv/tests/pip_install_scenarios.rs

zanieb · 2024-08-15T16:13:38Z

crates/uv/tests/pip_install_scenarios.rs

    ----- stderr -----
      × No solution found when resolving dependencies:
-      ╰─▶ Because only package-a<=1.2.3 is available and you require package-a>1.2.3, we can conclude that the requirements are unsatisfiable.
+      ╰─▶ Because only package-a==1.2.3+foo is available and you require package-a>1.2.3, we can conclude that the requirements are unsatisfiable.


Here we know there is exactly one version available, so we show that instead of a range.

zanieb · 2024-08-15T16:13:41Z

crates/uv/tests/pip_install_scenarios.rs

      ╰─▶ Because package-a==1.0.0 depends on package-b==1.0.0 and only the following versions of package-a are available:
              package-a==1.0.0
-              package-a>=2.0.0,<=3.0.0
+              package-a>2.0.0,<=3.0.0


This is the idea from #6071, there is no 2.0.0 so we shouldn't use >= here.

charliermarsh · 2024-08-15T16:58:29Z

crates/uv-resolver/src/pubgrub/report.rs

+            (Some(first), Some(last)) => {
+                let range = Range::<Version>::from_range_bounds((
+                    Bound::Included(first.clone()),
+                    Bound::Included(last.clone()),


Interesting... This should have holes in it, right? But my guess is it doesn't help / doesn't matter?

It basically doesn't matter in this case, we're just using it to check if the other range is completely out of bounds.

Maybe I should write a note for that, maybe there are some weird cases where the holes do matter?

I wrote it this way to avoid doing something like for version in available_versions { range.contains(version) } to see if the range contained all or none of the versions.

Yeah I think this is cool.

Added a note, we probably wont simplify some things that we could.

charliermarsh · 2024-08-15T17:00:34Z

crates/uv-resolver/src/pubgrub/report.rs

+            _ => (*upper).clone(),
+        };
+
+        new_range = new_range.union(&Range::from_range_bounds((lower, upper)));


I wonder if this is quadratic, and we should instead be collecting all the new ranges and then unioning them all at once at the end? But I don't see a way to do that in the Range API.

I wish. I think you can't just push segments yourself because it voids some guarantees.

I was hoping you could pass an iterator to union or something.

I added a note. We could follow-up in PubGrub. cc @konstin

charliermarsh

Makes sense.

charliermarsh · 2024-08-15T17:01:22Z

crates/uv-resolver/src/pubgrub/report.rs

+        // `foo>999`, and the the available versions are all `<10` it's useless to show.
+        if segment_range.is_disjoint(&available_range) {
+            continue;
+        }


What if the range is a singleton, and it's not in available versions?

(Is that impossible?)

Like this?

❯ uv add 'httpx==9999' ╰─▶ Because there is no version of httpx==9999 and example depends on httpx==9999, we can conclude that example's requirements are unsatisfiable. And because your workspace requires example, we can conclude that your workspace's requirements are unsatisfiable.

I think that's always handled before we get here. Otherwise, this operation is performed on the complement so I don't think it's possible.

Yeah like that. Ok I figured it was somehow handled upstream.

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.2.36` -> `0.2.37` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>astral-sh/uv (astral-sh/uv)</summary> ### [`v0.2.37`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0237) [Compare Source](astral-sh/uv@0.2.36...0.2.37) ##### Performance - Avoid cloning requirement for unchanged markers ([#6116](astral-sh/uv#6116)) ##### Bug fixes - Fix loading of cached metadata for Git distributions with subdirectories ([#6094](astral-sh/uv#6094)) ##### Error messages - Add env var to `--link-mode=copy` warning ([#6103](astral-sh/uv#6103)) - Avoid displaying "failed to download" on build failures for local source distributions ([#6075](astral-sh/uv#6075)) - Improve display of available package ranges ([#6118](astral-sh/uv#6118)) - Use "your requirements" consistently in resolver error messages ([#6113](astral-sh/uv#6113)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

zanieb added the error messages Messaging when something goes wrong label Aug 15, 2024

zanieb commented Aug 15, 2024

View reviewed changes

crates/uv/tests/pip_install_scenarios.rs Outdated Show resolved Hide resolved

zanieb commented Aug 15, 2024

View reviewed changes

zanieb force-pushed the zb/availability-range-real branch 2 times, most recently from 143c9d2 to 3f1c777 Compare August 15, 2024 16:24

zanieb marked this pull request as ready for review August 15, 2024 16:24

zanieb force-pushed the zb/availability-range-real branch from 3f1c777 to 1cb945d Compare August 15, 2024 16:27

zanieb mentioned this pull request Aug 15, 2024

Special case "only available" bounds in resolver errors #6071

Closed

zanieb requested a review from charliermarsh August 15, 2024 16:42

charliermarsh reviewed Aug 15, 2024

View reviewed changes

charliermarsh approved these changes Aug 15, 2024

View reviewed changes

charliermarsh reviewed Aug 15, 2024

View reviewed changes

Improve display of available package ranges

7cd52c5

zanieb force-pushed the zb/availability-range-real branch from 1cb945d to 7cd52c5 Compare August 15, 2024 17:21

zanieb enabled auto-merge (squash) August 15, 2024 17:22

zanieb merged commit 0efdbcc into main Aug 15, 2024

zanieb deleted the zb/availability-range-real branch August 15, 2024 17:28

BrewTestBot mentioned this pull request Aug 16, 2024

uv 0.2.37 Homebrew/homebrew-core#181339

Merged

zanieb mentioned this pull request Oct 4, 2024

Incorrect available versions with empty versions range #3307

Closed

Improve display of available package ranges #6118

Improve display of available package ranges #6118

Uh oh!

Conversation

zanieb commented Aug 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

charliermarsh Aug 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

charliermarsh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zanieb commented Aug 15, 2024 •

edited

Loading

charliermarsh Aug 15, 2024 •

edited

Loading