-
Notifications
You must be signed in to change notification settings - Fork 785
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-resolver: add new UniversalMarker
type
#9334
base: main
Are you sure you want to change the base?
Commits on Nov 21, 2024
-
uv-pep508: add a clarifying test
This test demonstrates the difference between `extra != "foo"` and `sys_platform != "foo"`. I wrote this test down to test the extra simplification logic was correct. And I also wanted to test whether we could somehow hackily encode `group` (as opposed to just `extra`) logic into marker expressions by reusing another field. But I don't think we can.
Configuration menu - View commit details
-
Copy full SHA for 3419829 - Browse repository at this point
Copy the full SHA 3419829View commit details -
uv-resolver: remove 'fork.is_false()' filtering
This filtering is now redundant, since forking now avoids these degenerate cases by construction. The main change to forking that enables skipping over "always false" forks is that forking now starts with the parent's markers instead of starting with MarkerTree::TRUE and trying to combine them with the parent's markers later. This in turn leads to skipping over anything that "can't" happen when combined with the parents markers. So we never hit the case of generating a fork that, when combined with the parent's markers, results in a marker that is always false. We just avoid it in the first place.
Configuration menu - View commit details
-
Copy full SHA for c36ad34 - Browse repository at this point
Copy the full SHA c36ad34View commit details -
uv-resolver: simplify
fork_markers
constructionThis doesn't change any behavior. My guess is that this code was a casualty of refactoring. But basically, it was doing redundant case analysis and iterating over all resolutions (even though it's in the branch that can only occur when there is only one resolution).
Configuration menu - View commit details
-
Copy full SHA for fbe5f50 - Browse repository at this point
Copy the full SHA fbe5f50View commit details -
uv-resolver: remove 'package_markers'
This was completely unused. I noticed this while trying to read and understand the code. It's unclear when or how this happened.
Configuration menu - View commit details
-
Copy full SHA for 8c190c2 - Browse repository at this point
Copy the full SHA 8c190c2View commit details -
uv/pip/compile: slightly simplify conflicts
This doesn't change any behavior. But this makes it a bit clearer in the code that `uv pip compile` does not support specifying conflicts. Indeed, we always pass an empty set of conflicts to the resolver. This is because there is no way to encode the conditional logic of conflicts into the `requirements.txt` format. This is unlike markers.
Configuration menu - View commit details
-
Copy full SHA for 0e4ced6 - Browse repository at this point
Copy the full SHA 0e4ced6View commit details -
uv-resolver: introduce new UniversalMarker type
This effectively combines a PEP 508 marker and an as-yet-specified marker for expressing conflicts among extras and groups. This just defines the type and threads it through most of the various points in the code that previously used `MarkerTree` only. Some parts do still continue to use `MarkerTree` specifically, e.g., when dealing with non-universal resolution or exporting to `requirements.txt`. This doesn't change any behavior.
Configuration menu - View commit details
-
Copy full SHA for 4645037 - Browse repository at this point
Copy the full SHA 4645037View commit details