The Fast Path: Cache, Preparation, and Installation
For uv, speed begins after the resolver has chosen a conditional set of packages. The question is how that set becomes files in a Python environment: which work can be reused, which work must be downloaded or built, and which filesystem changes can happen at the same time. Tracing uv's planner, cache, preparer, and installer lets a reader understand both the source of its performance and the conditions under which a fast path becomes unsafe or simply unavailable.
The distinction matters because “installation” hides several different costs. Reading metadata is not the same as downloading a wheel. Downloading a source archive is not the same as building it. Unzipping a wheel is not the same as placing its files into an environment. A useful design can overlap some of these tasks while preserving the ordering and integrity checks that make the final environment coherent.
From a resolved graph to an installation plan
The resolver produces package choices, but it does not immediately overwrite the target environment. uv first compares the resolution with what is already installed and with what is present in its cache. The install planner partitions the work: some distributions can be linked from cached material, some need to be downloaded or built, and some installed packages need to be removed. The plan respects freshness rules and required hashes, so a cached file is not automatically acceptable merely because it has the right package name.
This separation gives the system a point at which intent becomes filesystem work. The resolver answers which distributions are wanted under the dependency graph. The planner answers what must change to make the environment reflect that answer. If the environment already contains a compatible package, it may avoid unnecessary replacement. If the user requested a reinstall or a refresh, the planner can disregard some previously reusable state. If exact synchronization is in effect, packages outside the selected resolution become removal work rather than harmless leftovers.
The next stage is preparation. uv's preparer takes the distributions that the plan cannot immediately link and fetches, builds, and unzips them. A pre-built wheel can be downloaded and unpacked. A source distribution may need an isolated build before it yields a wheel. Both paths end with a prepared distribution that can be checked against the requested package identity and hash policy. This is why the resolution–artifact boundary matters: the installer does not treat an arbitrary archive as an already valid package.
Preparation is concurrent, but it is not careless. uv uses a stream of in-flight tasks so multiple distributions can be fetched, built, or unzipped while other work is waiting on network or filesystem operations. It also keeps an in-flight registry for a distribution identity. If two parts of the request need the same artifact, the second operation can wait for the first rather than repeating the download or build. This is especially valuable in workspaces and complex graphs, where the same package can be reached through multiple dependency paths.
The preparer validates the result before handing it onward. A cached or newly produced wheel must correspond to the requested name and, where applicable, version. Its archive hash must satisfy the required policy.