Fork version selection based on wheel Python version tags by charliermarsh · Pull Request #18587 · astral-sh/uv

charliermarsh · 2026-03-20T14:24:14Z

Summary

In #15069, the latest version of pywin32 doesn't include a Python 3.7 wheel. With this PR, we fork if a wheel-only distribution has a lower-bound below our requires-python bound so that each fork can choose a version with a compatible wheel.

Closes #15069.

codspeed-hq · 2026-03-20T14:39:12Z

Merging this PR will not alter performance

❌ 1 regressed benchmark
✅ 4 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	`BASE`	`HEAD`	Efficiency
❌	WallTime	`resolve_warm_airflow`	496.1 ms	514.3 ms	-3.52%

_{Comparing charlie/fork-wheels (896ea11) with main (d5f1325)}

charliermarsh · 2026-03-25T00:44:32Z

test/ecosystem/transformers/pyproject.toml

 description = "State-of-the-art Machine Learning for JAX, PyTorch and TensorFlow"
 keywords = ["NLP", "vision", "speech", "deep", "learning", "transformer", "pytorch", "tensorflow", "jax", "BERT", "GPT-2", "Wav2Vec2", "ViT"]
-requires-python = ">=3.9.0"
+requires-python = ">=3.9.0,<3.12"


This is a bit unfortunate, but tensorflow>=2.6,<2.16 legitimately doesn't have a wheel for Python 3.12...

Is this new upper bound required, or did you it for some other reason? Cause I wouldn't want to make it required when we otherwise recommend against upper bounds.

It's required, because the resolution below ends up forking on Python version during the course of solving, so we have a branch with >=3.12 that tries to include tensorflow>=2.6,<2.16, which doesn't have a valid wheel in that range, so it's a broken solution.

We could instead add this as a supported environments field rather than bounding requires-python. Or we could decide we don't want these semantics, and we could limit this behavior to the user-defined requires-python range (e.g., we need wheels at least for Python 3.9).

konstin · 2026-03-25T11:12:59Z

crates/uv/tests/it/pip_compile.rs

+    torchvision==0.15.1 ; (python_full_version < '3.12' and platform_machine == 'aarch64' and platform_python_implementation == 'CPython' and sys_platform == 'linux') or sys_platform == 'darwin'
        # via -r requirements.in
-    torchvision==0.15.1+rocm5.4.2 ; platform_machine == 'x86_64' and sys_platform != 'darwin'
+    torchvision==0.15.1+cu118 ; (python_full_version >= '3.12' and sys_platform == 'linux') or (platform_machine != 'aarch64' and sys_platform == 'linux') or (platform_python_implementation != 'CPython' and sys_platform == 'linux') or (sys_platform != 'darwin' and sys_platform != 'linux')


Why did we switch accelerator here?

zanieb · 2026-03-25T20:58:47Z

Is this related to #15932 ?

charliermarsh · 2026-03-26T22:14:55Z

Yeah, I think it's a similar idea. I am wondering if we should change this PR to only enforce the minimum Python version, though, to avoid problems like the "Tensorflow doesn't have a 3.12 wheel" issue.

konstin · 2026-03-27T09:25:33Z

I filed mhammond/pywin32#2726 cause the combination of no source dist and no requires-python metadata is rare, most projects have requires-python these days, which is a lot lighter on the resolver complexity-wise.

charliermarsh · 2026-03-27T13:28:11Z

I mean, I think we should still support some version of this? It's a bug, and requires-python is not the same thing.

konstin · 2026-03-27T13:33:29Z

How would requires-python and an inferred bound from Python version tags act different here? Maybe I'm missing what this PR is trying to do. Or do we do want to support it with an upper bound? This would then be a design decision about whether we want upper-bounds in requires-python in user packages when we ignore then for dependency packages.

charliermarsh · 2026-03-27T13:42:58Z

It's plausible that you could publish a package that supports Python 3.8 and later (e.g., requires-python: >=3.8), but only publish wheels for Python 3.12 (as an example), and no sdist.

The goal of this PR is that we would not accept that version as a valid solution for Python 3.8 through Python 3.11 (unless the user's own project only supports Python 3.12 and later).

konstin · 2026-03-27T13:52:14Z

That's seem like an odd combination, how would the package be compatible with 3.8, when there's no option to install it before 3.12? To me, this sounds more like a mistake in the metadata annotations. I know we had this case with an ML package before (torch or tensorflow), but there it was a mistake on their side and they fixed the bound to match the published wheels in the next release.

charliermarsh · 2026-03-27T13:54:08Z

I don't think it's an incorrect combination though. The code can support Python versions for which they don't publish wheels.

charliermarsh · 2026-03-27T13:54:20Z

I don't understand why we wouldn't want to handle that case correctly?

konstin · 2026-03-27T14:01:01Z

crates/uv/tests/it/snapshots/it__ecosystem__transformers-lock-file.snap

@@ -1532,43 +1503,43 @@ wheels = [

 [[package]]
 name = "h5py"
-version = "3.11.0"
+version = "3.11.[X]"


That looks like a too broad redaction.

konstin · 2026-03-27T14:02:28Z

I agree that this is correct logic-wise, but I'm worried about the added complexity in the already complex logic around implied/requested platform support and forking. requires-python seems to solve this in a much simpler way with the code we already support.

I don't think it's an incorrect combination though. The code can support Python versions for which they don't publish wheels.

Do we have packages for which this is the case?

charliermarsh · 2026-03-27T14:28:58Z

PyTorch 2.5.1: #14836

charliermarsh · 2026-03-27T14:30:10Z

If we only care about enforcing the minimum requires-python for the user's project, I suspect we can simplify the change. Right now, this attempts to enforce it in every fork.

charliermarsh · 2026-03-27T20:59:29Z

Okay, I pushed a commit that significantly simplifies things by only requiring that each chosen release has a wheel that's compatible with the minimum version in your requires-python.

charliermarsh force-pushed the charlie/fork-wheels branch 4 times, most recently from 350f7ef to 8e8f698 Compare March 24, 2026 13:06

charliermarsh added bug Something isn't working resolver Related to the package resolver labels Mar 24, 2026

charliermarsh changed the title ~~Re-compute supported Python range when forking~~ Fork version selection based on wheel Python version tags Mar 25, 2026

charliermarsh marked this pull request as ready for review March 25, 2026 00:44

charliermarsh requested review from konstin and zanieb March 25, 2026 00:44

charliermarsh commented Mar 25, 2026

View reviewed changes

charliermarsh force-pushed the charlie/fork-wheels branch 2 times, most recently from fd5df8a to 841e923 Compare March 25, 2026 03:02

konstin reviewed Mar 25, 2026

View reviewed changes

charliermarsh force-pushed the charlie/fork-wheels branch from 841e923 to 28894da Compare March 25, 2026 15:15

konstin reviewed Mar 27, 2026

View reviewed changes

Fork wheels

5cdcd68

charliermarsh added 4 commits March 27, 2026 15:57

Re-compute Python when forking

c09cbd9

Store index

987593c

Fix transformers

3001ad9

Use environments

9165c6e

charliermarsh force-pushed the charlie/fork-wheels branch from 28894da to c07e523 Compare March 27, 2026 20:54

charliermarsh marked this pull request as draft March 27, 2026 20:59

Limit to lower-bound

896ea11

charliermarsh force-pushed the charlie/fork-wheels branch from c07e523 to 896ea11 Compare March 27, 2026 21:15

Conversation

charliermarsh commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

codspeed-hq bot commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merging this PR will not alter performance

Performance Changes

Uh oh!

charliermarsh Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

konstin Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

charliermarsh Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

konstin Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

zanieb commented Mar 25, 2026

Uh oh!

charliermarsh commented Mar 26, 2026

Uh oh!

konstin commented Mar 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

charliermarsh commented Mar 27, 2026

Uh oh!

konstin commented Mar 27, 2026

Uh oh!

charliermarsh commented Mar 27, 2026

Uh oh!

konstin commented Mar 27, 2026

Uh oh!

charliermarsh commented Mar 27, 2026

Uh oh!

charliermarsh commented Mar 27, 2026

Uh oh!

konstin Mar 27, 2026

Choose a reason for hiding this comment

Uh oh!

konstin commented Mar 27, 2026

Uh oh!

charliermarsh commented Mar 27, 2026

Uh oh!

charliermarsh commented Mar 27, 2026

Uh oh!

charliermarsh commented Mar 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

charliermarsh commented Mar 20, 2026 •

edited

Loading

codspeed-hq bot commented Mar 20, 2026 •

edited

Loading

konstin commented Mar 27, 2026 •

edited

Loading