Why Is It Designed This Way?

Why resolve before installing?

Mutation should not be used as a search procedure. A complete resolution lets uv report conflicts, create a reproducible lock, calculate removals, and prepare artifacts before disturbing the environment.

Why start many metadata requests?

Network latency dominates individual index lookups, while the resolver may need many independent facts. Overlap reduces wall time; the bounded request channel, deduplication, and deeper semaphores prevent unlimited resource use.

Why have separate concurrency budgets?

Fifty HTTP responses, fifty Python compilers, and fifty filesystem installers have radically different costs. One global permit pool would either starve cheap I/O or overload CPU, memory, child processes, and file handles.

Nested builds and command helpers are part of the same process-wide load. If each layer interpreted “8 builds” independently, composition would multiply the promised limit.

Why deduplicate in-flight operations?

Dependency graphs converge: several packages may request the same metadata or artifact before the cache is populated. Waiting on one producer saves work and ensures all callers observe one result.

Why make the cache append-oriented and atomic?

Immutable entries are easy to share between threads, processes, and uv versions. Publishing with rename turns partial construction into a private detail and makes interruption recoverable.

Why lock the environment but not serialize the whole cache?

Independent artifacts can safely be prepared concurrently. site-packages is a shared multi-file namespace where overlapping uninstall/install operations would corrupt ownership. The narrow lock preserves both speed and correctness.

Why use external Python processes?

Python build backends and bytecode compilation are Python-defined behavior. Subprocess isolation respects that ecosystem boundary and limits failures, while bounded workers keep the orchestration under Rust’s control.