[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#54539] [PATCH 0/6] Start breaking up import cycles
From: |
Maxime Devos |
Subject: |
[bug#54539] [PATCH 0/6] Start breaking up import cycles |
Date: |
Tue, 19 Apr 2022 11:40:39 +0200 |
User-agent: |
Evolution 3.38.3-1 |
Ludovic Courtès schreef op di 19-04-2022 om 11:17 [+0200]:
> If you follow the logic, breaking up import cycles would mean, in the
> end, having one file per package.
Not necessarily, (gnu packages minetest) has multiple packages
(minetest and some of its mods) but it doesn't cause any cycles (no
other module, except sort-of (guix build-system minetest), imports it.)
That one appears to be, at least currently, a bit of a special case
though.
> But would that be enough? Probably not, because low-level packages
> are bound to depend on high-level packages—e.g., glibc depends on
> Python, some other low-level tool might depend on Pandoc (GHC),
> librsvg depends on Rust, and so on.
>
> IOW, since the graph of build dependency really is a graph, and not a
> tree, there’ll always be import cycles.
The graph of build dependencies (in terms of derivations) is a tree,
the build daemon doesn't allow cyclic derivations. So I think that by
letting the module graph be a coarser version of the derivation graph
but still a tree (except for the bootstrap packages gcc, sed, ... whose
modules may import each other).
> (guix self), the module that ‘guix pull’ uses, already automatically
> splits package modules into two groups. It’s not as modular as we’d
> like, but it’s a start. What would be useful is to come up with metrics
> and tools to reduce the closure of the “guix-packages-base” group.
>
> WDYT?
Maybe:
a tool that determines a minimal set of (importing module ->
imported module tuples) that needs to be lazified to reduce the
closure size (in number of modules) in guix-packages-base by N
and:
extend "guix style" to perform these changes
Maybe the ‘number of imports lazified -> number of modules in guix-
packages-base’ function has some sweet spot somewhere.
I think it would be easier though to work our way up before going to
"guix pull" -- first "hello", then "util-linux, then "guile-avahi",
then "guile-ssh", then "sqlite" ... and only eventually guix itself.
Also, even if the closure of "guix-packages-base" cannot be reduced,
making it (mostly) a tree would allow splitting the group into multiple
parts (see ‘Faster "guix pull" by incremental compilation and non-
circular modules?’).
Alternative:
* make _all_ package module imports lazy -- #:autoload everything!
guix-packages-base might then need to be set manually though ...
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part