Hi, On Wednesday, December 10th, 2025 at 11:21 AM, Tomas Volf <[email protected]> wrote:
> > > Cayetano Santos [email protected] writes: > > > This is why I’m thinking a bout something as simple as: > > > > guix build qucs-s > > /gnu/store/lfg34wzx83mjla81kh38yjpx0r7xq43i-qucs-s-25.2.0 total : 2749.2 Mio > > > Please no. It would break usage of guix build in scripting. I have few > scripts where I am doing stuff like jq=$(guix build jq)/bin/jq ... That is a valid concern. I think the way to handle adding the extra information would be to print it out on stderr just like the rest of the build output. On a different note (sparked when testing "guix build jq > out" and seeing two substitutes being downloaded), I think it would be difficult to get a meaningful size printed out. Right now "guix size" prints the size of the package and all of its (runtime) dependencies, but having that size printed out could be misleading. For example, installing icecat would show a size that includes all of its X, Wayland, PulseAudio, etc. dependencies that are shared among other packages. Showing the size for the package's entire closure of dependencies would be misleading as it would suggest the package in question is that big (when it is not) especially if only a few dependencies are substituted (i.e. the number is counting a lot of things the user does not see in the command's output). It would be compounded when building two or more packages at the same time (e.g. "guix build icecat mpv"), where either a) "guix build" would either report overly large sizes for each package with shared dependencies being included in each size, or b) a single combined size would be reported for all of the packages with dependencies deduplicated (their size only counting once). Option b would arguably be more accurate but I suspect the numbers would be seen as "untrustworthy" without knowledge of how and what is being computed, as the sizes from e.g. "guix build icecat" and "guix build mpv" would add up to a lot more than the size reported by "guix build icecat mpv". Both issues--which also have the problem of what is contributing to the size--could be avoided by just printing the size of package(s) specified on the command line without dependencies, but I suspect that would be of minimal value outside of maybe package development. All of that is to say, I agree that more tracking and reigning in of the sizes of packages is a very good thing, but I don't thing simply printing the size at the end of "guix build" or "guix lint" would help that--particularly given that I think knowing the size of a package isn't very useful on it's own, with the more relevant information when modifying or upgrading a package is the change in the size. For example, if I upgrade package "foo" from version 1.3 to 2.0, knowing the package is 182MB isn't actionable, but seeing that the package went from 119MB with v1.3 to 182MB with v2.0 would be a huge flag that closer examination of the upgrade is needed. Cheers, Kaelyn > > Tomas > > -- > There are only two hard things in Computer Science: > cache invalidation, naming things and off-by-one errors.
