[bug#54539] [PATCH 0/6] Start breaking up import cycles

[zimoun]

Hi Maxime,

On Fri, 25 Mar 2022 at 18:46, Maxime Devos <maximedevos@telenet.be> wrote:
> zimoun schreef op vr 25-03-2022 om 18:05 [+0100]:

> > To be honest, I am not sure to understand the aim of reorganizing the
> > modules... I mean, to me, the only important metrics is the
> > performance of the end-user.  If there is no performance improvement
> > when cutting cycle, then it appears to me pointless to cut cycles. :-)
>
> FWIW, there are three goals here:
>
>   * Allowing writing stuff like
>
>     (use-modules (gnu packages ncurses))
>     (package
>       (name "some-terminal-app")
>       [...]
>       ;; Work-around the ‘search path of dependencies not propagated’ bug.
>       (native-search-paths (package-native-search-paths ncurses)))
>
>     without getting 'unbound variable' errors.
>     Alternatively, the search-path-specification could be defined in,
>     say, (guix search-paths) next to $PATH but that proposal seems
>     to have been rejected.
>
>   * Making "compute-guix-derivation" faster by reducing the number of
>     (uncompiled!) package module files it needs to load.
>
>   * Eventually making the ‘incremental compilation’ by fine-grained 
> derivations
>     proposal from the ‘Faster "guix pull" by incremental compilation and
>     non-circular modules?’ thread [0] feasible.

Thanks for the detailed and clear explanations.  It was my initial
understanding that cutting cycles can improve the performances, and
IMHO, timings are required for comparing apple to apple; as I tried to
explain [1].  Then the thread have let me the impression that the
performance improvement was not the aim -- thanks for clarifying.

1: <https://issues.guix.gnu.org/54539#12>

> (*) FWIW, on my machine, "guix show guix" takes 1.6s.

To be precise, "guix show guix" could be drastically improved by
adapting the already existing package.cache, i.e., resume the lengthy
work of <https://issues.guix.gnu.org/39258>. :-)

However, such cache would be useless for "guix show -L path/to/others
foo" where performance can be really poor; especially on spinning hard
disk.  Well, thanks for working on that by trying to tackle the cycle
of modules.


Cheers,
simon