Re: Speeding up “guix pull”: splitting modules

[zimoun <zimon.toutoune@gmail.com>]

Hi Gábor,

Thank you for the explanations.

Below, I am thinking loudly. :-)

On Tue, 7 Jan 2020 at 21:14, Gábor Boskovits <boskovits@gmail.com> wrote:

> > > Gábor 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 less
> > > 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. :-)
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, right?


Aside, a naive question: does '#:select' improve the situation?



All the best,
simon