Handle universal vs. fork markers with ResolverMarkers (#5099)

* Use a dedicated `ResolverMarkers` check in the fork state. This is
better than the `MarkerTree::And(Vec::new())` check.
* Report the timing correct naming universal resolution instead of two
spaces around an empty string when there are no markers.
* On resolution error, show the split that we're in. I'm not sure how to
word this, since we're doing a universal resolution until we fork, so
the trace may contain information from requirements that are not part of
this fork.
This commit is contained in:
konsti 2024-07-17 18:59:33 +02:00 committed by GitHub
parent fe403576c5
commit a6dfd3953a
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
19 changed files with 220 additions and 133 deletions

View file

@ -26,6 +26,7 @@ use uv_installer::{Installer, Plan, Planner, Preparer, SitePackages};
use uv_python::{Interpreter, PythonEnvironment};
use uv_resolver::{
ExcludeNewer, FlatIndex, InMemoryIndex, Manifest, OptionsBuilder, PythonRequirement, Resolver,
ResolverMarkers,
};
use uv_types::{BuildContext, BuildIsolation, EmptyInstalledPackages, HashStrategy, InFlight};
@ -146,7 +147,7 @@ impl<'a> BuildContext for BuildDispatch<'a> {
.index_strategy(self.index_strategy)
.build(),
&python_requirement,
Some(markers),
ResolverMarkers::SpecificEnvironment(markers.clone()),
Some(tags),
self.flat_index,
self.index,