uv-types

crates/uv-types/ holds trait abstractions used by multiple uv crates to break what would otherwise be circular dependencies.

Purpose

The resolver needs to call into the build frontend to build sdists for metadata. The installer needs to call into the resolver to upgrade. These cross-crate calls would create cycles if every crate referenced its consumers directly — Cargo forbids that. The fix: trait abstractions that live in uv-types, with concrete implementations in the binary crate.

Key abstractions

• BuildContext — the trait the resolver / installer use to request a built sdist or a resolved environment.
• BuildIsolation — Shared / Isolated / SharedPackage(...) toggle for builds.
• BuildStack — recursion-detection stack to avoid infinite build loops.
• InstalledPackagesProvider — abstracts "what packages are currently installed?"
• HashStrategy — controls hash verification policies (generate, verify, none).
• SourceBuildTrait — the contract the build frontend implements.
• ResolvedRequirements, AnyErrorBuild, ExtraBuildRequires — supporting types.

Why a separate crate

It would be tempting to put these traits in uv-distribution or uv-installer, but every trait either consumes or produces types that live in another core crate. Pulling them up into uv-types lets every consumer depend on a shared, dependency-light vocabulary.

See also

• uv-resolver, uv-installer, uv-build-frontend all depend on this crate.