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

[Liliana Marie Prikler]

Am Donnerstag, dem 24.03.2022 um 16:05 +0100 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 24-03-2022 om 08:22 [+0100]:
> > I agree that breaking up cycles is a good thing, but I disagree
> > with some of the decisions you've made here.  For instance, I
> > oppose the use of single-package modules, because those more often
> > than not simply clutter the file system.
> 
> There are some other sound applications in (gnu packages audio)
> and (gnu packages music), so maybe I can make a (gnu packages audio-
> apps) module where 'audacity' and other applications like 'calf' can
> reside?
I'm not sure.  IIUC, audio should be for audio systems, codecs, etc.
whereas music sounds like a particular niche containing music players
etc.  Perhaps the cycle could more appropriately been broken by moving
stuff from music to audio?  Alternatively, declaring music as lazy
import as shown in my previous mail might help making these
interdependencies both "cycle-free" and visible.  (I'm pretty sure we
also have "sound" lying around somewhere to put more oil into the
fire.)

> For reducing the contribution of (gnu packages compression) on the
> cycle issue, I've (in not yet submitted patched) separated many
> things into (gnu packages compression-xyz), perhaps I can merge
> (gnu packages patools) into (gnu packages compression-xyz)?
Here too, I think a classification into compression algorithms in
compression and backup/archival tools in another file (we do have
backup IIRC) would make the most sense.  Though obviously, we'd have to
do compression algorithms implemented in Rust in a special rust-
compression file to avoid circles or use the cycle killer lambda trick.
I'm not sure if "compression-xyz" would be a helpful label, and it
might just become the next root of circular dependencies if abused.

Cheers