6ed6fc108e
This is like #9556, but at the level of all other builds, including the resolver and installer. Going through PEP 517 to build a package is slow, so when building a package with the uv build backend, we can call into the uv build backend directly instead: No temporary virtual env, no temp venv sync, no python subprocess calls, no uv subprocess calls. This fast path is gated through preview. Since the uv wheel is not available at test time, I've manually confirmed the feature by comparing `uv venv && cargo run pip install . -v --preview --reinstall .` and `uv venv && cargo run pip install . -v --reinstall .`. When hacking the preview so that the python uv build backend works without the setting the direct build also (wheel built with `maturin build --profile profiling`), we can see the perfomance difference: ``` $ hyperfine --prepare "uv venv" --warmup 3 \ "UV_PREVIEW=1 target/profiling/uv pip install --no-deps --reinstall scripts/packages/built-by-uv --preview" \ "target/profiling/uv pip install --no-deps --reinstall scripts/packages/built-by-uv --find-links target/wheels/" Benchmark 1: UV_PREVIEW=1 target/profiling/uv pip install --no-deps --reinstall scripts/packages/built-by-uv --preview Time (mean ± σ): 33.1 ms ± 2.5 ms [User: 25.7 ms, System: 13.0 ms] Range (min … max): 29.8 ms … 47.3 ms 73 runs Benchmark 2: target/profiling/uv pip install --no-deps --reinstall scripts/packages/built-by-uv --find-links target/wheels/ Time (mean ± σ): 115.1 ms ± 4.3 ms [User: 54.0 ms, System: 27.0 ms] Range (min … max): 109.2 ms … 123.8 ms 25 runs Summary UV_PREVIEW=1 target/profiling/uv pip install --no-deps --reinstall scripts/packages/built-by-uv --preview ran 3.48 ± 0.29 times faster than target/profiling/uv pip install --no-deps --reinstall scripts/packages/built-by-uv --find-links target/wheels/ ``` Do we need a global option to disable the fast path? There is one for `uv build` because `--force-pep517` moves `uv build` much closer to a `pip install` from source that a user of a library would experience (See discussion at #9610), but uv overall doesn't really make guarantees around the build env of dependencies, so I consider the direct build a valid option. Best reviewed commit-by-commit, only the last commit is the actual implementation, while the preview mode introduction is just a refactoring touching too many files. |
||
|---|---|---|
| .. | ||
| uv | ||
| uv-auth | ||
| uv-bench | ||
| uv-build-backend | ||
| uv-build-frontend | ||
| uv-cache | ||
| uv-cache-info | ||
| uv-cache-key | ||
| uv-cli | ||
| uv-client | ||
| uv-configuration | ||
| uv-console | ||
| uv-dev | ||
| uv-dirs | ||
| uv-dispatch | ||
| uv-distribution | ||
| uv-distribution-filename | ||
| uv-distribution-types | ||
| uv-extract | ||
| uv-fs | ||
| uv-git | ||
| uv-globfilter | ||
| uv-install-wheel | ||
| uv-installer | ||
| uv-macros | ||
| uv-metadata | ||
| uv-normalize | ||
| uv-once-map | ||
| uv-options-metadata | ||
| uv-pep440 | ||
| uv-pep508 | ||
| uv-performance-flate2-backend | ||
| uv-performance-memory-allocator | ||
| uv-platform-tags | ||
| uv-publish | ||
| uv-pypi-types | ||
| uv-python | ||
| uv-requirements | ||
| uv-requirements-txt | ||
| uv-resolver | ||
| uv-scripts | ||
| uv-settings | ||
| uv-shell | ||
| uv-state | ||
| uv-static | ||
| uv-tool | ||
| uv-trampoline | ||
| uv-trampoline-builder | ||
| uv-types | ||
| uv-version | ||
| uv-virtualenv | ||
| uv-warnings | ||
| uv-workspace | ||
| README.md | ||
README.md
Crates
uv-bench
Functionality for benchmarking uv.
uv-cache-key
Generic functionality for caching paths, URLs, and other resources across platforms.
uv-distribution-filename
Parse built distribution (wheel) and source distribution (sdist) filenames to extract structured metadata.
uv-distribution-types
Abstractions for representing built distributions (wheels) and source distributions (sdists), and the sources from which they can be downloaded.
uv-install-wheel-rs
Install built distributions (wheels) into a virtual environment.
uv-once-map
A waitmap-like concurrent hash map for executing tasks
exactly once.
uv-pep440-rs
Utilities for interacting with Python version numbers and specifiers.
uv-pep508-rs
Utilities for parsing and evaluating dependency specifiers, previously known as PEP 508.
uv-platform-tags
Functionality for parsing and inferring Python platform tags as per PEP 425.
uv-cli
Command-line interface for the uv package manager.
uv-build-frontend
A PEP 517-compatible build frontend for uv.
uv-cache
Functionality for caching Python packages and associated metadata.
uv-client
Client for interacting with PyPI-compatible HTTP APIs.
uv-dev
Development utilities for uv.
uv-dispatch
A centralized struct for resolving and building source distributions in isolated environments.
Implements the traits defined in uv-types.
uv-distribution
Client for interacting with built distributions (wheels) and source distributions (sdists). Capable of fetching metadata, distribution contents, etc.
uv-extract
Utilities for extracting files from archives.
uv-fs
Utilities for interacting with the filesystem.
uv-git
Functionality for interacting with Git repositories.
uv-installer
Functionality for installing Python packages into a virtual environment.
uv-python
Functionality for detecting and leveraging the current Python interpreter.
uv-normalize
Normalize package and extra names as per Python specifications.
uv-requirements
Utilities for reading package requirements from pyproject.toml and requirements.txt files.
uv-resolver
Functionality for resolving Python packages and their dependencies.
uv-shell
Utilities for detecting and manipulating shell environments.
uv-types
Shared traits for uv, to avoid circular dependencies.
uv-pypi-types
General-purpose type definitions for types used in PyPI-compatible APIs.
uv-virtualenv
A venv replacement to create virtual environments in Rust.
uv-warnings
User-facing warnings for uv.
uv-workspace
Workspace abstractions for uv.
uv-requirements-txt
Functionality for parsing requirements.txt files.