-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Build backend: Add direct builds to the resolver and installer #9621
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
d006891
to
4d7f4fd
Compare
See discussion at #9610 (comment)
We want to add direct builds that don't go through PEP 517 to the resolver and installer, too, after they now exist in `uv build`. These need to be hidden behind preview for now. For that, we need to thread the preview mode through to the build dispatch.
Move check_direct_build to uv-build-backend and add a parameter for logging. When using this function as part of the resolver or installer, the log messages will otherwise be lacking context.
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 .`. 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 (comment)
b927433
to
87823cf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, looks great!
crates/uv-dispatch/src/lib.rs
Outdated
subdirectory: Option<&'data Path>, | ||
output_dir: &'data Path, | ||
build_kind: BuildKind, | ||
version_id: Option<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a Option<&str>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. It would be kinda annoying, but doable. I don't feel strongly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's more converting back and forth now, but it's also move consistent with the rest of the codebase.
crates/uv-dispatch/src/lib.rs
Outdated
output_dir: &'data Path, | ||
build_kind: BuildKind, | ||
version_id: Option<String>, | ||
) -> Result<Option<String>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is being returned here? And should it be a PathBuf
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh okay, it's documented below on the trait.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This initially happened because PEP 517 says that the build backend returns the filename as last line, and we passed that around as a string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More specifically, the location on disk may not be normalized the same as WheelFilename
is, so for non-uv build backends we have to pass out a string and only parse later, i added comments.
/// Build by calling directly into the uv build backend without PEP 517, if possible. | ||
/// | ||
/// Checks if the source tree uses uv as build backend. If not, it returns `Ok(None)`, otherwise | ||
/// it builds and returns the name of the built file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does it return in the case of an editable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this stage, the editable is a wheel that is indistinguishable from a regular wheel, except it contains a .pth
file instead of the actual sources (but we still unpack it the regular way) and we're not allowed to cache it.
Were you able to find any benchmarks showing an improvement? I guess they would be cold runs right? |
With hacking the preview so that the python uv build backend works without the setting the direct build also (wheel built with
|
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.5.6` -> `0.5.7` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>astral-sh/uv (astral-sh/uv)</summary> ### [`v0.5.7`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#057) [Compare Source](astral-sh/uv@0.5.6...0.5.7) ##### Enhancements - Ignore dynamic version in source dist ([#​9549](astral-sh/uv#9549)) - Improve build frontend error handling ([#​9611](astral-sh/uv#9611)) - Un-hide `uv build --no-build-logs` option ([#​9642](astral-sh/uv#9642)) - Flag version mismatch between sdist and wheel during `uv build` ([#​9633](astral-sh/uv#9633)) - Improve message when updater receipt is for a different uv executable ([#​9487](astral-sh/uv#9487)) - Add environment variable to disable writing installer metadata files ([#​8877](astral-sh/uv#8877)) - Add managed downloads for the latest CPython releases: `3.9.21`, `3.10.16`, `3.11.11`, `3.12.8`, and `3.13.1` ([#​9696](astral-sh/uv#9696)) ##### Preview features - Build backend: Add hint on import with preview disabled ([#​9691](astral-sh/uv#9691)) - Build backend: Add direct builds to the resolver and installer ([#​9621](astral-sh/uv#9621)) - Build backend: Add integration test for scripts ([#​9635](astral-sh/uv#9635)) - Build backend: Add template to `uv init` ([#​9661](astral-sh/uv#9661)) - Build backend: Add `--list` option ([#​9610](astral-sh/uv#9610)) ##### Bug fixes - Create missing parent directories for output file of `uv export` / `uv pip compile` ([#​9648](astral-sh/uv#9648)) - Fix missing display of non-freethreaded Python 3.13 in `python list` ([#​9669](astral-sh/uv#9669)) - Implement `Ord` and `PartialOrd` without origin for `Requirement` ([#​9624](astral-sh/uv#9624)) - Include more sources to avoid lowest bound warning ([#​9644](astral-sh/uv#9644)) - Respect build tag priority in `uv.lock` ([#​9677](astral-sh/uv#9677)) ##### Documentation - Add `build-essentials` note to build failures doc ([#​9641](astral-sh/uv#9641)) - Add entry-point for distroless image in GitLab documentation ([#​9093](astral-sh/uv#9093)) - Add documentation for `uv python pin` without a `REQUEST` argument ([#​9631](astral-sh/uv#9631)) - Add a link to `uv python pin` reference docs ([#​9630](astral-sh/uv#9630)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40NDAuNyIsInVwZGF0ZWRJblZlciI6IjM3LjQ0MC43IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
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 .
anduv 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 withmaturin build --profile profiling
), we can see the perfomance difference:Do we need a global option to disable the fast path? There is one for
uv build
because--force-pep517
movesuv build
much closer to apip 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.