Add `uv tree --show-sizes` to show package sizes by harsh-ps-2003 · Pull Request #15531 · astral-sh/uv

harsh-ps-2003 · 2025-08-26T13:42:45Z

Summary

Adds the enhancement proposed in #15470. Each package in the dependency tree now shows its compressed wheel file size, reading the wheel sizes directly from the lockfile (uv.lock). Doesn't break existing tree formatting or options. If no wheel size is available, nothing is added.

Now, developers can identify large packages in their dependency tree.

The tree still shows extras exactly as before, and then appends a size for the package.

Test Plan

Manually tested :

harsh@fcr-node:~/uv/test-uv-tree-sizes$ ../target/debug/uv tree
Using CPython 3.13.7
warning: No `requires-python` value found in the workspace. Defaulting to `>=3.13`.
Resolved 4 packages in 6ms
pure-python v0.1.0
├── click v8.2.1
└── six v1.17.0
harsh@fcr-node:~/uv/test-uv-tree-sizes$ ../target/debug/uv tree --show-sizes
Using CPython 3.13.7
warning: No `requires-python` value found in the workspace. Defaulting to `>=3.13`.
Resolved 4 packages in 6ms
pure-python v0.1.0
├── click v8.2.1 (99.8KiB)
└── six v1.17.0 (10.8KiB)

zanieb · 2025-08-26T14:01:20Z

I think this should probably be gated by --show-sizes

zanieb · 2025-08-26T18:10:22Z

crates/uv-resolver/src/lock/tree.rs

+    clippy::cast_possible_truncation,
+    clippy::cast_possible_wrap,
+    clippy::cast_precision_loss,
+    clippy::cast_sign_loss


Do we need to do all this? Doesn't wrapping or sign loss seem important?

I saw a very similar implementation here.

Just being a bit practical here, file sizes rarely exceed the precision limits of f32 and the slight precision loss should be acceptable for display purposes. They don't seem practically important to me, so I prioritised usability over mathematical precision.

Ah okay if that's pre-existing that seems fine. Can we share the implementation somewhere?

The CLI (crates/uv) cannot be depended on by uv-resolver, so if we strictly want to share, we will need to put it in an existing low-level crate. I don't think exporting a UI-ish formatter from uv-resolver as a public API is great for boundaries.

Again, being a bit practical here, this ~10 LOC duplication keeps dependencies simple. If we expect more byte-formatting call sites or want strict DRY, then maybe some sort of micro-crate is worth it. Otherwise, keeping both copies is not that bad.

It's less about LOC duplication and more about it being a pretty obscure implementation that opts out of a bunch of our typical safety rules.

I think we could move it into uv-fs, uv-normalize, or some other shared crate.

The uv-fs is filesystem utilities; bytes-to-human is unrelated, and uv-normalise normalises names; not generic formatting. What do you think of uv-types? It’s a low-level, tiny, pure helper, which is safe for both crates to depend on, from which both call sites can import it cleanly.

🤷‍♀️ I don't think uv-types is any better really, it's just a display function not a type that we need to share across a bunch of interfaces. We could also use uv-console or uv-logging.

zanieb · 2025-08-26T18:11:33Z

crates/uv/src/commands/project/tree.rs

    );
+    if show_sizes {
+        tree = tree.with_show_sizes(true);
+    }


Why use a .with... pattern here instead of passing the value to new like all the other settings?

zanieb · 2025-08-26T18:13:33Z

We'll need a new test case in it/tree. What does this do with extras?

harsh-ps-2003 · 2025-08-27T08:48:05Z

What does this do with extras?

It's orthogonal to extras. The size is taken from the first wheel in the lockfile that has a size field. Extras do not change which size is shown; there’s no per-extra size.

harsh-ps-2003 · 2025-08-27T16:11:50Z

I think the failing test is a flake!

zanieb · 2025-08-28T18:07:41Z

I can't push the fix

diff --git a/Cargo.lock b/Cargo.lock
index a65e547f1..11368662b 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -6241,6 +6241,7 @@ dependencies = [
  "uv-cache-key",
  "uv-client",
  "uv-configuration",
+ "uv-console",
  "uv-distribution",
  "uv-distribution-filename",
  "uv-distribution-types",

harsh-ps-2003 · 2025-08-29T09:32:36Z

I can't push the fix

I pushed for you, but Docker images are failing now! Weird

zanieb · 2025-08-29T13:31:38Z

The Docker image auth is a GitHub issue.

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.8.14` -> `0.8.15` | 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.15`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0815) [Compare Source](astral-sh/uv@0.8.14...0.8.15) ##### Python - Upgrade SQLite 3.50.4 in CPython builds for [CVE-2025-6965](GHSA-2m69-gcr7-jv3q) (see also [python/cpython#137134](python/cpython#137134)) ##### Enhancements - Add `uv auth` commands for credential management ([#15570](astral-sh/uv#15570)) - Add pyx support to `uv auth` commands ([#15636](astral-sh/uv#15636)) - Add `uv tree --show-sizes` to show package sizes ([#15531](astral-sh/uv#15531)) - Add `--python-platform riscv64-unknown-linux` ([#15630](astral-sh/uv#15630)) - Add `--python-platform` to `uv run` and `uv tool` ([#15515](astral-sh/uv#15515)) - Add `uv publish --dry-run` ([#15638](astral-sh/uv#15638)) - Add zstandard support for wheels ([#15645](astral-sh/uv#15645)) - Allow registries to pre-provide core metadata ([#15644](astral-sh/uv#15644)) - Retry streaming Python and binary download errors ([#15567](astral-sh/uv#15567)) ##### Bug fixes - Fix settings rendering for `extra-build-dependencies` ([#15622](astral-sh/uv#15622)) - Skip non-existent directories in bytecode compilation ([#15608](astral-sh/uv#15608)) ##### Error messages - Add error trace to invalid package format ([#15626](astral-sh/uv#15626)) </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. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

pablofueros · 2025-12-03T12:05:23Z

Hello everyone. Thanks for this PR, i also proposed this idea a few months ago on #11883 it's great to see it implemented.

Just wanted to also point it out here, if repeated packages existis, sizes could not be shown more than one time (in my Issue I suggest an idea for that). With this, the total sum computation would trivial, and that was my actual concern, just to make an idea of the total project size.

add size in uv tree

f0d6a60

harsh-ps-2003 added 4 commits August 26, 2025 20:16

gate by --show-sizes

81a6896

clippy nit

ec01a1d

add references for cli

e3fa4a9

fmt and test nit

027647d

zanieb reviewed Aug 26, 2025

View reviewed changes

harsh-ps-2003 added 2 commits August 27, 2025 00:12

nit

a292384

test for flag

6fb6c07

Merge branch 'astral-sh:main' into size

c9b5c60

zanieb changed the title ~~add size in uv tree~~ Add uv tree --show-sizes to show package sizes Aug 27, 2025

harsh-ps-2003 added 2 commits August 28, 2025 00:31

moving human_readable_bytes to uv-console

8e98cf5

fmt nit

6f3baa0

zanieb approved these changes Aug 27, 2025

View reviewed changes

Merge branch 'astral-sh:main' into size

0781fe0

nit

1c29da5

zanieb merged commit d877899 into astral-sh:main Aug 29, 2025
146 of 157 checks passed

harsh-ps-2003 deleted the size branch August 29, 2025 15:31

BrewTestBot mentioned this pull request Sep 3, 2025

uv 0.8.15 Homebrew/homebrew-core#236027

Merged

charliermarsh mentioned this pull request Dec 3, 2025

uv tree to show package size #15470

Closed

Conversation

harsh-ps-2003 commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test Plan

Uh oh!

zanieb commented Aug 26, 2025

Uh oh!

zanieb Aug 26, 2025

Choose a reason for hiding this comment

Uh oh!

harsh-ps-2003 Aug 26, 2025

Choose a reason for hiding this comment

Uh oh!

zanieb Aug 26, 2025

Choose a reason for hiding this comment

Uh oh!

harsh-ps-2003 Aug 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zanieb Aug 27, 2025

Choose a reason for hiding this comment

Uh oh!

harsh-ps-2003 Aug 27, 2025

Choose a reason for hiding this comment

Uh oh!

zanieb Aug 27, 2025

Choose a reason for hiding this comment

Uh oh!

zanieb Aug 26, 2025

Choose a reason for hiding this comment

Uh oh!

zanieb commented Aug 26, 2025

Uh oh!

harsh-ps-2003 commented Aug 27, 2025

Uh oh!

harsh-ps-2003 commented Aug 27, 2025

Uh oh!

zanieb commented Aug 28, 2025

Uh oh!

harsh-ps-2003 commented Aug 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zanieb commented Aug 29, 2025

Uh oh!

Uh oh!

pablofueros commented Dec 3, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

harsh-ps-2003 commented Aug 26, 2025 •

edited

Loading

harsh-ps-2003 Aug 27, 2025 •

edited

Loading

harsh-ps-2003 commented Aug 29, 2025 •

edited

Loading