From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: =?UTF-8?Q?Re=3A_Speeding_up_=E2=80=9Cguix_pull=E2=80=9D=3A_splitting_modules?= Date: Fri, 10 Jan 2020 13:42:26 +0100 Message-ID: References: <87k1657i7j.fsf@elephly.net> 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]:45897) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iptcn-00021q-0J for guix-devel@gnu.org; Fri, 10 Jan 2020 07:42:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iptcl-0005yU-LY for guix-devel@gnu.org; Fri, 10 Jan 2020 07:42:48 -0500 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:33414) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iptcl-0005m6-CS for guix-devel@gnu.org; Fri, 10 Jan 2020 07:42:47 -0500 Received: by mail-ed1-x529.google.com with SMTP id r21so1416257edq.0 for ; Fri, 10 Jan 2020 04:42:47 -0800 (PST) In-Reply-To: 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: zimoun Cc: Guix Devel Hello zimoun, zimoun ezt =C3=ADrta (id=C5=91pont: 2020. jan. 1= 0., P, 13:10): > > Hi G=C3=A1bor, > > Thank you for the explanations. > > Below, I am thinking loudly. :-) > > On Tue, 7 Jan 2020 at 21:14, G=C3=A1bor Boskovits w= rote: > > > > > G=C3=A1bor once suggested an iterative approach of identifying the = most > > > > important nodes in the package graph that should be moved to their = own > > > > modules, so that we would end up with a package graph that looks le= ss > > > > like a hair ball. I think it would useful to get a better view on = the > > > > relationships between modules. > > [...] > > > I was suggesting the following idea: > > The underlying package graph is actually a DAG, so by splitting modules= it is > > possible to achieve a state where the module graph also becomes a DAG. > > The exact heuristic or algorithm of splitting was not defined. > > The modules graph (DAG) is already available. :-) The main problem here is that the modules do not form a DAG. There are circular dependencies between the modules. If those were not, then modular build would be possible, but because of the spaghetti we are forced to build these together. > Modulo some glue code / tweaks, the tools are already in > guix/graph.scm and guix/scripts/graph.scm, if I understand correctly. > And note that the commit ddd59159004ca73c9449a27945116ff5069c3743 > introduces topological sort -- for another topic: recursive import -- > but could be reused /adapted to detect cycles, IMHO. > > Would a weighted DAG help to detect which modules are in "bad shape"? > Other said, mix somehow the packages DAG and the modules DAG? > > For example, the edge between the module m1 and the module m2 should > be weighted by the ratio between the number of packages defined in the > module m2 required in the module m1. > So then, sorting this edges by weight value, it would give a better > view of the relationship between modules. > > What do you think? > > We need to detect which "big" modules are imported for "few" packages, ri= ght? > > > Aside, a naive question: does '#:select' improve the situation? I don't know, but it is an interesting question. > > > > All the best, > simon Best regards, g_bor --=20 OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21