nix store gc --dry-run: print paths

[dtzWill]

Fixes #5704 .

Functionality is basic, and indeed code was copied from how it's already done here for non-experimental version:

nix/src/nix-store/nix-store.cc

Line 605 in f3f32f0

if (options.action != GCOptions::gcDeleteDead)

---

Would add a test, but there appears no tests for nix store gc in-tree so wasn't sure where to put it (and adding new test/setup seems beyond scope here). If there's a good place let me know 😄.

I'm seeing many ways to print things, so mostly just did what we already do for this but maybe that's not right for new code-- LMK and happy to fix 👍.

(seems sometimes with fmt("%s\n", x) and mix of newlines using << "\n" and << std::endl. Each with trade-offs re:allocations, race against other prints (possibly separating path from newline, maybe), and flushing behavior, I think?)

Anyway short fix for issue I filed earlier, apologies if this is in wrong direction haven't been following development very closely but wanted to chip in 😇.

Thanks!

[edolstra]

IMHO writing (potentially) thousands of paths to stdout that the user didn't ask for is not really good UX. It's also not obvious whether this should print the dead or alive paths. I think it would be better to add a --json flag, and then the JSON output could include both dead and alive paths.

For the non-JSON case, what it should print is something like "X paths (YYY.ZZ MiB) would be deleted".

[dtzWill]

Okay. Unfortunately the similarly trivial implementation doesn't quite work as GCResults's bytesFreed doesn't update the count in this case (although comment about the field declaration suggests it does, FWIW). Haven't looked into how hard plumbing that through the relevant code would be, unsure at a glance 😄. I'm briefly concerned some stuff (like link cleanup?) might be more of a "do it and count as you go" sort of situation (delete until count is 1, or whatever) but I don't know.

I'm interested but unsure when I can commit, apologies.

---

Quick test/sample of this here: dtzWill@46f4002, not pushing because it doesn't work (as described above) and can't mark this as draft myself apparently (boo, PR authors should be able to surely? anyway). And maybe poking at PrintFreed to handle the "would be" language, but perhaps not. Presumably it's the way it is now so that exceptions during GC still print what was freed or something?

Anyway, this seems more than I can tackle immediately but maybe in a bit I can poke at the relevant code 👍.

Thanks for taking a look and no worries glad for such concerns as what is good UX. Especially for the new cli! 😁.

A --json option seems neat, and straightforward enough to add. Sounds good to me 👍.

[stale]

I marked this as stale due to inactivity. → More info

[Ericson2314]

Draft because reviewer and author agreed on other approach.

[tomberek]

stale: re-open and re-base as needed