[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Speeding up “guix pull”: splitting modules

From: Ricardo Wurmus
Subject: Re: Speeding up “guix pull”: splitting modules
Date: Fri, 10 Jan 2020 20:02:53 +0100
User-agent: mu4e 1.2.0; emacs 26.3

zimoun <address@hidden> writes:

> On Wed, 8 Jan 2020 at 22:50, Ludovic Courtès <address@hidden> wrote:
>> Ricardo Wurmus <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]