Install non-build-isolation packages in a second phase#15306
Install non-build-isolation packages in a second phase#15306charliermarsh merged 2 commits intomainfrom
Conversation
5fece32 to
1fffd8b
Compare
1fffd8b to
a2d2ed4
Compare
crates/uv/tests/it/sync.rs
Outdated
| Uninstalled 5 isolated packages in [TIME] | ||
| Prepared 1 non-isolated package in [TIME] | ||
| Uninstalled 1 non-isolated package in [TIME] | ||
| Installed 1 non-isolated package in [TIME] |
There was a problem hiding this comment.
This was a bit tedious (the labels) but I think it makes a big difference.
There was a problem hiding this comment.
I have a couple thoughts....
- "isolated" and "non-isolated" seem a little vague, though I think it's nice it's only present if you're using
no-build-isolation, you could be runninguv syncin a project where you did not configure that. I wonder if we should drop "isolated" and say "packages without build isolation" (or similar) for the non-isolated case? - I wonder if we can get away with repeating the prefix, e.g., if having it on "Prepared" is sufficient?
Uninstalled 5 packages in [TIME]
Prepared 1 package without build isolation in [TIME]
Uninstalled 1 package in [TIME]
Installed 1 package in [TIME]
I guess if we have a cached wheel.. it'd just say "Uninstalled" twice in a row though?
There was a problem hiding this comment.
I think what you have in that snippet is probably good (just putting it on "prepared").
| /// | ||
| /// Any extraneous and cached distributions will be returned in the first plan, while the second | ||
| /// plan will contain any `false` matches from the remote distributions, along with any | ||
| /// reinstalls for those distributions. |
There was a problem hiding this comment.
The behavior here is a bit subtle. I tried to document it clearly.
| )?; | ||
|
|
||
| // Running `uv sync` should fail. | ||
| uv_snapshot!(context.filters(), context.sync().arg("--no-build-isolation-package").arg("source-distribution"), @r#" |
There was a problem hiding this comment.
Oh! I totally missed this on a first read. Could we just move this into the pyproject.toml?
There was a problem hiding this comment.
We can, the other tests also do this so I was kind of mirroring the style.
There was a problem hiding this comment.
I think I'd prefer it, if there aren't invocations that don't want it.
There was a problem hiding this comment.
I will do it in a separate PR where I change it for all of the tests in this group.
4f63917 to
781c499
Compare
781c499 to
6d849de
Compare
crates/uv/tests/it/sync.rs
Outdated
| Prepared 1 isolated package in [TIME] | ||
| Installed 1 isolated package in [TIME] |
There was a problem hiding this comment.
Should these be changed like the pip_install test?
6d849de to
c55b398
Compare
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.8.11` -> `0.8.12` | 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.8.12`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0812) [Compare Source](astral-sh/uv@0.8.11...0.8.12) ##### Python - Add 3.13.7 - Improve performance of zstd in Python 3.14 See the [python-build-standalone release notes](https://github.com/astral-sh/python-build-standalone/releases/tag/20250818) for details. ##### Enhancements - Add an `aarch64-pc-windows-msvc` target for `python-platform` ([#​15347](astral-sh/uv#15347)) - Add fallback parent process detection to `uv tool update-shell` ([#​15356](astral-sh/uv#15356)) - Install non-build-isolation packages in a second phase ([#​15306](astral-sh/uv#15306)) - Add hint when virtual environments are included in source distributions ([#​15202](astral-sh/uv#15202)) - Add Docker images derived from `buildpack-deps:trixie`, `debian:trixie-slim`, `alpine:3.22` ([#​15351](astral-sh/uv#15351)) ##### Bug fixes - Reject already-installed wheels built with outdated settings ([#​15289](astral-sh/uv#15289)) - Skip interpreters that are not found on query ([#​15315](astral-sh/uv#15315)) - Handle dotted package names in script path resolution ([#​15300](astral-sh/uv#15300)) - Reject `match-runtime = true` for dynamic packages ([#​15292](astral-sh/uv#15292)) ##### Documentation - Document improvements to build-isolation setups ([#​15326](astral-sh/uv#15326)) - Fix reference documentation recommendation to use `uv cache clean` instead of `clear` ([#​15313](astral-sh/uv#15313)) </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:eyJjcmVhdGVkSW5WZXIiOiI0MS43Ni4wIiwidXBkYXRlZEluVmVyIjoiNDEuNzYuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90Il19-->
Summary
This PR productionizes an idea I saw in #15248, which was added in Pixi: prefix-dev/pixi#4247. The core of the idea is that if we install all build isolation-enabled packages first, and the build isolation-disabled packages in a second phase, the sync is more likely to "just work", because if all the build dependencies of the build isolation-disabled packages are included as dependencies (as is the case for
flash-attn, at least), they'll be present.This isn't really a silver bullet, because it requires that all the build dependencies are included as first-party dependencies, and if you have packages that want build isolation to be disabled but rely on other packages that also require build isolation disabled, that won't work either. I think
extra-build-dependencieswill be more robust and have much better caching behavior, but this will get more cases right than our current behavior, and I don't see any downsides.Closes #15301.