Re: Speeding up “guix pull”: splitting modules

[Ricardo Wurmus <rekado@elephly.net>]

zimoun <zimon.toutoune@gmail.com> writes:

> On Wed, 8 Jan 2020 at 22:50, Ludovic Courtès <ludo@gnu.org> wrote:
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> > On the other hand: this would need to be an ongoing effort.  Newly
>> > introduced packages or even new features might create complex module
>> > cycles.  It sounds tedious to keep track of this and to enforce
>> > boundaries.
>>
>> Yes, I think this is a dead end: glibc could well end up become on
>> Haskell (hi, Pandoc!), and then the whole module split effort collapses.
>
> What kind of metrics could help to detect which modules are going to
> the wrong way?
> For example, would some DAG post-processings help?

I don’t think it’s feasible to clean up the module graph in a way that
can be kept clean long enough.  Ideally we wouldn’t need to think about
Guile modules at all, so the best screw to turn appears to be in the
Guile compiler and not in Guix.

--
Ricardo