guix-patches
[Top][All Lists]
Advanced

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

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


From: Ludovic Courtès
Subject: [bug#54539] [PATCH 0/6] Start breaking up import cycles
Date: Tue, 19 Apr 2022 11:17:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> skribis:

> Import cycles make some packaging things harder and prevent some
> proposed optimisations to "guix pull", let's start eliminating them.
> TBC ...

Sorry for the late reply.

Some of the changes you propose may make sense (and should be applied),
but we shouldn’t overplay the role of such changes.

If you follow the logic, breaking up import cycles would mean, in the
end, having one file per package.

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.

(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?

Thanks,
Ludo’.





reply via email to

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