From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Guix size reduction work group Date: Mon, 10 Feb 2020 00:45:58 +0100 Message-ID: References: <87pneul50i.fsf@ambrevar.xyz> <87blqdnjuv.fsf@gnu.org> <875zghdo7j.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:55016) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j0wHJ-0008Dc-0w for guix-devel@gnu.org; Sun, 09 Feb 2020 18:46:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j0wHH-0006jp-UB for guix-devel@gnu.org; Sun, 09 Feb 2020 18:46:16 -0500 In-Reply-To: <875zghdo7j.fsf@ambrevar.xyz> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: Guix Devel Hi Pierre, On Sat, 8 Feb 2020 at 17:43, Pierre Neidhardt wrote: > >> - Improve the tooling. In my experience, guix graph is quickly unusab= le > >> with a high number of nodes. Maybe d3.js could be leveraged to add = a > >> filtering system, or a way to click on nodes to hide them and all > >> their children. > > > > =E2=80=98guix size=E2=80=99 is key here: it=E2=80=99s a profiler, exact= ly what we need IMO. > > WDYT? > > Maybe I'm missing something, but in general I think that guix size only > gives a birds eye view and does not allow for closer inspection. > > Say FOO has BAR in its closure, but not in the explicit inputs, how can > I figure out which of the indirect inputs drags BAR in? I do not understand what you are looking for, but there is already: guix graph -t reverse-package guix graph -t reverse-bag that does more or less what I understand you want. > With an extensive guix graph, it quickly becomes impossible to follow > the millions of arrows. Using a static graphviz, I agree. And I generally end up by grepping directly in the 'dot' output file. Maybe something more dynamic using 'd3.js' or similar to view *big* graphs could help. > What I'd like to have is an interactive graph that I can trim to links > between given nodes. This would allow me to ask "give me the dependency > chain that links FOO and BAR". I agree that tools to work with the graph would be welcome. Currently, the graph is here but under-used, IMHO. The first step seems to list what operations and filtering is missing. > > The thing is, I think it=E2=80=99s something that requires constant car= e, every > > time we add a package or modify an existing one. It=E2=80=99s very eas= y to lose > > benefits that had been previously obtained through hard work! > > This is a good point. "Adding" a package is less critical since it does > not impact the closure size of the rest. For "updates" maybe we could > leverage the continuous integration to flag a warning when a new build > has increased the size of the package compared to a previous build by > some threshold. 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 All the best, simon