[charliermarsh]

Summary

This changes the default for prune-cache from true to false, motivated by #745. Users that want the existing behavior can continue to set prune-cache: true explicitly.

Some history: I originally added uv cache prune --ci after looking at a workload where the uv cache was ~2.2 GB, almost entirely due to the enormous pre-built torch and nvidia_cudnn_cu12 wheels (original analysis). Persisting and restoring thousands of extracted files through the GitHub Actions cache could be slower than downloading the wheels again. In contrast, wheels built from source can be very expensive to recreate. The intent was to remove pre-built wheels while retaining locally-built wheels.

setup-uv subsequently made pruning configurable, but defaulted prune-cache to true; it also later enabled caching by default on GitHub-hosted runners. As a result, the default configuration repeatedly downloads pre-built wheels from PyPI even on a cache hit. That tradeoff has become more important as uv adoption has grown: the PyPI analysis in #745 estimates that uv accounts for roughly half of reported CI downloads from PyPI, and roughly 65-75% for boto3.

I ran the comparison across a few different workloads:

Workload	PR	Packages	Cache: keep / prune / prune-ci	Warm restore+sync: keep / prune / prune-ci	Downloads: prune / prune-ci
Tiny	#1	19	6 / 6 / 2 MB	0.3-0.4 / 0.3 / 0.4-0.5 s	0 / 2
Web	#2	65	43 / 43 / 7 MB	0.6-1.0 / 0.5-0.6 / 1.5-1.7 s	0 / 6
Scientific	#3	118	586 / 586 / 8 MB	8.2-16.0 / 7.0-8.2 / 8.9-12.1 s	0 / 19
PySpark	#4	19	1820 / 1820 / 436 MB	9.9-21.1 / 10.5-11.0 / 5.0-7.0 s	0 / 4
CPU PyTorch	#5	14	182 / 182 / 1 MB	3.0-6.0 / 3.6-4.0 / 5.7-6.4 s	0 / 6
CPU-PyTorch ML	#6	137	346 / 346 / 10 MB	7.4-18.0 / 8.8-8.9 / 9.7-11.9 s	0 / 20
CUDA PyTorch	#7	201	2316 / 2315 / 16 MB	30.2-67.9 / 31.0-63.6 / 33.3-36.7 s	0 / 40

The CUDA workload intentionally reproduces the original torch==2.1.1 example. Keeping wheels again produces a ~2.3 GB Actions cache. Across nine warm runs, restoring that cache ranged from slightly faster than re-downloading to roughly twice as slow; pruning consistently re-downloaded 40 distributions in ~33-37 seconds (original runs, additional runs).

I also tried running uv cache prune --force without --ci across every workload, to see if it provided a useful middle ground. It did not meaningfully reduce any of the caches: plain prune took 11-21 ms and left the extracted cache and file count unchanged, including PySpark. On these fresh caches, there are no dangling entries to remove; without --ci, the pre-built wheels and unpacked source/build artifacts are retained. The per-workload runs are linked in the table above.

So the original motivation still holds for very large CUDA or source-heavy workloads, but it is not representative of the common case. For smaller workloads, keeping pre-built wheels is generally faster and avoids repeated PyPI traffic. This changes the default accordingly, while retaining prune-cache: true as an opt-in for workloads where the smaller cache is worthwhile.

Closes #745.

[zsol]

Could you try running the benchmark with uv cache prune (without --ci) too? I suspect that might be the sweet spot for a default

[charliermarsh]

I tested it and it removed 0 artifacts across all the test cases. It's generally just not that aggressive -- it removes things like obsolete cache buckets, ephemeral environments, etc.

[eifinger]

Thank you for the detailed analysis including statistics and the historical timeline

[eifinger]

For some users this might be a big surprise so I'm gonna flag this as a breaking change.