Pierre Neidhardt writes: > zimoun writes: > >> You could propose such feature to the Guix Data Service. >> For example, on this webpage [1], the history of all the Git package >> in Guix is shown. The closure size could be reported. >> >> [1] http://data.guix.gnu.org/repository/1/branch/master/package/git > > This is a great idea! Christopher, what do you think? I don't think adding to that particular page is feasible, but I think having a page just of this information would be great :) I'm not quite sure how that would work, but the Guix Data Service can query for narinfo files, and from those it can store the size of specific outputs, as well as there references. So the closure size (I think?) is the size of an output, plus the closure size of all of its references (the definition is recursive). Then you could compute the closure size for the output (or set of outputs) for a package, and then graph that over the different revisions on a branch. Because this is using information from builds, it's a little complicated by the information potentially varying between build server, for example, if the nar non-deterministically includes a reference. Going back to the point about preventing regressions though, there I think it would be good to enhance the comparision functionality of the Guix Data Service so that it can compare derivation outputs, and say how the closure size has changed. Then you could look at this when reviewing patches. Chris