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

[Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>]

Am Freitag, dem 25.03.2022 um 11:26 +0100 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 24-03-2022 om 16:38 [+0100]:
> > 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.
> > [...]
> 
> I'm not sure where the ‘I'm not sure’ comes from --- audacity is not
> an audio system like pulseaudio or alsa, not a codec implementation
> like libvorbis, and it is a sound player (and editor), so IIUC,
> audacity does not fit into (gnu packages audio).
It's not particularly specific to audacity in this case, it's that I
think that "-app" does not make for a useful distinction.  Consider
fluidsynth.  Is it an app, a library, something else?  If fluidsynth
was causing circular imports and moving it to audio-synthesizers fixed
things, that'd be fine by me.  gnaural could also fit into
synthesizers.  However, putting both in the same file might still be an
issue from a cycle perspective, because the latter needs gtk, whereas
the former is content with having just glib (although that one appears
benign on surface, as at the very least gtk does not audio directly).

> While it can be used for modifying and playing music, it is more
> general than that, hence the suggestion of (gnu packages audio-apps)
> (where some other packages can be moved to as well, maybe
> 'gnaural'?).
> 
> Though granted, it's difficult to make a strict distinction between
> audio and music.
> 
> >   Perhaps the cycle could more appropriately been broken by moving
> > stuff from music to audio?
> 
> (gnu packages music) is full of applications using gtk+ or gles or
> the like.  Moving them to (gnu packages audio) would make (gnu
> packages audio) depend on (gnu packages gtk) and friends, which seems
> counter-productive to me.
That's the status quo (through gnaural and audacity for example).  To
make a more educated guess, which cycle do we aim to address here?  Is
there a meaningful cut that can be made (e.g. the offending packages
are all "audio editors", "audio synthesizers", etc.) or do we have to
separate good and bad based on their inputs?

Cheers