-
Notifications
You must be signed in to change notification settings - Fork 988
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
Avoid narrowing requires-python
marker with disjunctions
#10704
Conversation
1b83917
to
9c22987
Compare
ef5c8f0
to
59ff621
Compare
59ff621
to
08878b0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the potential simplification I pointed out this looks good to me! A little surprised that we didn't notice this bug sooner.
crates/uv-resolver/src/marker.rs
Outdated
/// `MarkerTreeKind::True` node. | ||
fn collect_python_markers( | ||
tree: MarkerTree, | ||
markers: &mut Vec<Vec<Ranges<Version>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The search here only cares about a single type of node (CanonicalMarkerValueVersion::PythonFullVersion
), and importantly that node can only show up once on a given solution path in the decision diagram. I believe this means that you shouldn't need an inner Vec
here, and you can default to Ranges::full()
for a solution that does not have an explicit python version requirement. That should simplify this a little bit — there is no list of versions to take the intersection of for a given solution.
fd49e53
to
6cbcccf
Compare
6cbcccf
to
e5e8e8f
Compare
Summary
A bug in
requires_python
(which infers the Python requirement from a marker) was leading us to break an invariant around the relationship between the marker environment and the Python requirement. This, in turn, was leading us to drop parts of the environment space when solving.Specifically, in the linked example, we generated a fork for
python_full_version < '3.10' or platform_python_implementation != 'CPython'
, which was later split intopython_full_version == '3.8.*'
andpython_full_version == '3.9.*'
, losing theplatform_python_implementation != 'CPython'
portion.Closes #10669.