Hi Maxime, Maxime Devos 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’.