Skip to content

feat(clean): report size of removed files#6053

Merged
ruben-arts merged 2 commits into
prefix-dev:mainfrom
baszalmstra:claude/pixi-clean-size-reporting-y507t
May 11, 2026
Merged

feat(clean): report size of removed files#6053
ruben-arts merged 2 commits into
prefix-dev:mainfrom
baszalmstra:claude/pixi-clean-size-reporting-y507t

Conversation

@baszalmstra
Copy link
Copy Markdown
Contributor

Description

pixi clean is now a tiny bit more rewarding: it tells you how much disk space you just liberated. Because "removed your environments" hits different when followed by "(4.2 GiB)".

The recursive deletion now sums file sizes as it goes. Each folder gets its own Removed <path> (<size>) line and the run ends with a bold Removed <total> summary.

Works for pixi clean, pixi clean --environment, pixi clean cache, and friends.

How Has This Been Tested?

  • cargo check -p pixi_cli
  • cargo clippy -p pixi_cli --all-targets -- -D warnings
  • cargo fmt --all -- --check
  • Manual: ran pixi clean and pixi clean cache on a real workspace,
    watched the spinner spin and the bytes add up.

AI Disclosure

  • This PR contains AI-generated content.
    • I have tested any AI-generated content in my PR.
    • I take responsibility for any AI-generated content in my PR.

Tools: Claude

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas

claude added 2 commits May 8, 2026 14:57
`pixi clean` and `pixi clean cache` now print the human-readable size of
each removed folder/file and a final total, so users can see how much
disk space was reclaimed.
Avoids the extra pre-walk to compute folder size: the recursive removal
now sums file sizes as it deletes, returning the total (or partial total
on error). The simple spinner showing the directory currently being
cleaned is unchanged.
@baszalmstra baszalmstra requested a review from ruben-arts May 8, 2026 15:59
@baszalmstra
Copy link
Copy Markdown
Contributor Author

@ruben-arts This is ready

@ruben-arts
Copy link
Copy Markdown
Contributor

I did a similar test as in this PR: #5218

➜ hyperfine -p 'pixi exec -s pytorch python --version' "PIXI_CACHE_DIR=/tmp/pixi_cache pi
xi clean cache --yes" "PIXI_CACHE_DIR=/tmp/pixi_cache pixi-6053 clean cache --yes" -w 1
Benchmark 1: PIXI_CACHE_DIR=/tmp/pixi_cache pixi clean cache --yes
  Time (mean ± σ):      3.296 s ±  0.051 s    [User: 0.025 s, System: 2.539 s]
  Range (min … max):    3.212 s …  3.373 s    10 runs
 
Benchmark 2: PIXI_CACHE_DIR=/tmp/pixi_cache pixi-6053 clean cache --yes
  Time (mean ± σ):      3.575 s ±  0.064 s    [User: 0.046 s, System: 2.796 s]
  Range (min … max):    3.469 s …  3.688 s    10 runs
 
Summary
  PIXI_CACHE_DIR=/tmp/pixi_cache pixi clean cache --yes ran
    1.08 ± 0.03 times faster than PIXI_CACHE_DIR=/tmp/pixi_cache pixi-6053 clean cache --yes

It's a non significant slowdown but I'm not sure what the change would be if the cache was even larger. Do you think the UX improvement is more important than speed?

@baszalmstra
Copy link
Copy Markdown
Contributor Author

I can deep dive what is causing that but I assume the extra stat calls.

I do think showing how much is actually removed (barring links) is much better yes!

@wolfv
Copy link
Copy Markdown
Member

wolfv commented May 11, 2026

@ruben-arts just to be sure, did you compile in release mode?

@ruben-arts
Copy link
Copy Markdown
Contributor

@ruben-arts just to be sure, did you compile in release mode?

I did, pixi = main pixi-6053 is this PR.

@ruben-arts ruben-arts merged commit b64b915 into prefix-dev:main May 11, 2026
37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants