Bump ossf/scorecard-action from 2.4.0 to 2.4.3 - #4
Open
dependabot[bot] wants to merge 1 commit into
Open
Conversation
dependabot
Bot
added
dependencies
dependabot
Bot
force-pushed
the
dependabot/github_actions/ossf/scorecard-action-2.4.3
branch
from
January 5, 2026 05:55
d0f69f2 to
dbd5e22
Compare
Bumps [ossf/scorecard-action](https://github.com/ossf/scorecard-action) from 2.4.0 to 2.4.3. - [Release notes](https://github.com/ossf/scorecard-action/releases) - [Changelog](https://github.com/ossf/scorecard-action/blob/main/RELEASE.md) - [Commits](ossf/scorecard-action@62b2cac...4eaacf0) --- updated-dependencies: - dependency-name: ossf/scorecard-action dependency-version: 2.4.3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/github_actions/ossf/scorecard-action-2.4.3
branch
from
January 5, 2026 05:59
dbd5e22 to
a597211
Compare
github-actions Bot
added a commit
that referenced
this pull request
Aug 14, 2026
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#5391) 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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) | 19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 | | Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) | 65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 | | Scientific | [#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 | 586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 | | PySpark | [#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 | 1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 | | CPU PyTorch | [#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 | 346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 | | CUDA PyTorch | [#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738), [additional runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)). 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 astral-sh/setup-uv#745.
github-actions Bot
added a commit
that referenced
this pull request
Aug 14, 2026
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#5391) 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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) | 19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 | | Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) | 65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 | | Scientific | [#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 | 586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 | | PySpark | [#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 | 1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 | | CPU PyTorch | [#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 | 346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 | | CUDA PyTorch | [#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738), [additional runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)). 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 astral-sh/setup-uv#745.
github-actions Bot
added a commit
that referenced
this pull request
Aug 14, 2026
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#5391) 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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) | 19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 | | Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) | 65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 | | Scientific | [#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 | 586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 | | PySpark | [#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 | 1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 | | CPU PyTorch | [#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 | 346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 | | CUDA PyTorch | [#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738), [additional runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)). 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 astral-sh/setup-uv#745.
github-actions Bot
added a commit
that referenced
this pull request
Aug 14, 2026
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#5391) 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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) | 19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 | | Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) | 65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 | | Scientific | [#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 | 586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 | | PySpark | [#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 | 1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 | | CPU PyTorch | [#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 | 346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 | | CUDA PyTorch | [#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738), [additional runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)). 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 astral-sh/setup-uv#745.
Raj-StepSecurity
pushed a commit
that referenced
this pull request
Aug 14, 2026
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#5391) 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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) | 19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 | | Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) | 65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 | | Scientific | [#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 | 586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 | | PySpark | [#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 | 1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 | | CPU PyTorch | [#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 | 346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 | | CUDA PyTorch | [#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738), [additional runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)). 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 astral-sh/setup-uv#745.
Raj-StepSecurity
pushed a commit
that referenced
this pull request
Aug 14, 2026
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#5391) 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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) | 19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 | | Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) | 65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 | | Scientific | [#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 | 586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 | | PySpark | [#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 | 1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 | | CPU PyTorch | [#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 | 346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 | | CUDA PyTorch | [#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738), [additional runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)). 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 astral-sh/setup-uv#745.
Raj-StepSecurity
pushed a commit
that referenced
this pull request
Aug 14, 2026
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#5391) 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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) | 19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 | | Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) | 65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 | | Scientific | [#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 | 586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 | | PySpark | [#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 | 1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 | | CPU PyTorch | [#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 | 346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 | | CUDA PyTorch | [#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738), [additional runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)). 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 astral-sh/setup-uv#745.
Raj-StepSecurity
pushed a commit
that referenced
this pull request
Aug 14, 2026
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#5391) 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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) | 19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 | | Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) | 65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 | | Scientific | [#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 | 586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 | | PySpark | [#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 | 1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 | | CPU PyTorch | [#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 | 346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 | | CUDA PyTorch | [#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/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](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738), [additional runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)). 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 astral-sh/setup-uv#745.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps ossf/scorecard-action from 2.4.0 to 2.4.3.
Release notes
Sourced from ossf/scorecard-action's releases.
Commits
4eaacf0bump docker to ghcr v2.4.3 (#1587)42e3a01🌱 Bump the github-actions group with 3 updates (#1585)88c07ac🌱 Bump github.com/sigstore/cosign/v2 from 2.5.2 to 2.6.0 (#1579)6c690f2Bump github.com/ossf/scorecard/v5 from v5.2.1 to v5.3.0 (#1586)92083b5📖 Fix recommended command to test the image in development (#1583)7975ea6🌱 Bump the docker-images group across 1 directory with 2 updates (#1...0d1a743🌱 Bump github.com/spf13/cobra from 1.9.1 to 1.10.1 (#1575)46e6e0c🌱 Bump the github-actions group with 2 updates (#1580)c3f1350🌱 Improve printing options (#1584)43e475b🌱 Bump golang.org/x/net from 0.42.0 to 0.44.0 (#1578)You can trigger a rebase of this PR by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)