the copy/download status when fetching flake lock archives is misleading/wrong

[colemickens]

Describe the bug

Hello! This is one of those things I've grown accustomed to but am really noticing on a slow connection, so I thought I'd fie it (I did try many searches first):

[3 copied (15.8 MiB), 24.0/9.2 MiB DL] downloading 'https://a...

It seems that when nix needs to fetch many things, it provides inaccurate output about how much it needs to download.

Steps To Reproduce

1. Do nix flake lock --recreate-lock-file where there are multiple flake input updates.
2. Use nix-direnv on the repo from another machine without the paths cached, particularly noticeable if you're on an excruciatingly slow connection.

Expected behavior

Lots of things might be "expected".

Minimally, it would be nice if the fetchers supported the concept of pre-fetching sizes of their targets (HEAD reqs? not sure...), and then that were used to give a proper estimate. Barring that, maybe don't provide the estimate. It seems borderline useless, when there are multiple inputs, especially on a repo that has many inputs, many of which move pretty frequently.

It's also seemingly not even just a matter of not knowing the sizes ahead of time, the downloaded byte count exceeds the estimate, even as both update throughout the entire process. Maybe there are multiple bugs at play?

Ideally, it would be slick if I saw a list of the archives, and their statuses. It also seems like they don't happen in parallel, but if they did, I could imagine output similar to docker layers or cachix, where multiple operations are shown in parallel, with their own status bars.

Thanks to maintainers!

nix-env --version output

$ nix --version
nix (Nix) 2.18.2

Additional context

Add any other context about the problem here.

Priorities

Add :+1: to issues you find important.