Overview
Across the uv 0.12.13 source snapshot, this series follows one request from project, script, tool, or legacy input through Python selection, conditional dependency resolution, artifact preparation, caching, environment synchronization, and execution. It explains how pyproject.toml, uv.lock, .venv, inline metadata, workspaces, and the uv pip bridge assign ownership at different scopes. The result is clearer diagnosis, repeatable handoffs, and potentially faster reuse—not a universal binary or hermetic build: package metadata, wheel availability, indexes, credentials, builds, host platforms, and package code remain outside uv’s control.
Learning outcomes
- uv connects interpreter selection, dependency resolution, artifacts, caching, environments, and execution across several workflow scopes.
- uv.lock records conditional resolved choices, but it cannot guarantee a compatible wheel or a hermetic build on every target.
- Projects, scripts, tools, workspaces, and uv pip workflows share machinery while keeping different declaration owners and environment lifetimes.
- uv’s speed comes from reuse and concurrency, with gains constrained by metadata, filesystem, artifact, and environment-lock conditions.
- Indexes, hashes, build isolation, and attestations address different controls; none proves that package code is safe.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What does uv coordinate in a Python workflow?
uv coordinates Python selection, dependency resolution, artifact preparation, caching, environment synchronization, and command execution. The same lifecycle serves projects, scripts, tools, and pip-compatible workflows with different owners and scopes.
Does uv.lock make a Python project reproducible on every platform?
No. uv.lock records exact conditional choices and artifact information, but reproducibility still depends on reachable indexes, credentials, metadata, build behavior, interpreter choice, and a compatible wheel or source build on the target.
Should a dependency belong to a uv project, script, or tool environment?
A repository-owned dependency belongs in the project; a standalone file can own its requirements through PEP 723 metadata; and an independent CLI belongs in uvx or uv tool install. Use the project environment when the command must import the project itself.
Why can uv installations be faster than repeated pip workflows?
uv can reuse cached metadata and artifacts, overlap downloads and builds, and install independent wheel files in parallel. The benefit depends on cache warmth, filesystem capabilities, package mix, operating system, and source-build cost, so benchmark ratios are workload-specific.
Is uv’s environment isolation a security sandbox?
No. uv’s separate project, script, and tool environments reduce dependency collisions, but package code can still run builds, inspect the interpreter, read files, use the network, or invoke host capabilities. Isolation controls coupling, not trust.