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.

As a side benefit, it makes the output of "guix graph --type=module foo"
less cluttered and presumably reduces the module closure (a likely
side-effect of breaking cycles), making "guix show foo" (*) a bit faster.

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

[0]: <https://lists.nongnu.org/archive/html/guix-devel/2022-02/msg00193.html>

Greetings,
Maxime.