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

[zimoun <zimon.toutoune@gmail.com>]

Hi Liliana and Maxime,

On Fri, 25 Mar 2022 at 09:44, Liliana Marie Prikler
<liliana.prikler@ist.tugraz.at> wrote:

> The question is (on a per-module basis) whether we consider this cheat
> fine or whether we want to move things into different files (and
> which).  I so far haven't heard a good argument for the case of
> audacity I raised.  "It breaks cycles" is not good enough when we
> consider the potential existence of other cuts (e.g. "audio-apps",
> although perhaps a more specific "audio-editors" similar to how we have
> "image-viewers" might make more sense), as well as the cheat of lazy
> imports.
>
> simon, you raise some important performance metrics, but there is such
> a thing as optimizing for the wrong metric.  There are other variables
> to consider, like time to grep, "does it make sense that X belongs to Y
> and Z doesn't", etc., when it comes to ease of contributing.  Declaring
> some modules banned for a given other module has an adverse effect
> here, in my opinion, and thus I claim that we need easily accessible
> ways of using those supposedly banned modules.

To be honest, I am not sure to understand the aim of reorganizing the
modules... I mean, to me, the only important metrics is the
performance of the end-user.  If there is no performance improvement
when cutting cycle, then it appears to me pointless to cut cycles. :-)

Moreover, set an arbitrary boundary between packages is... arbitrary.
You can spend close to eternity for discussing "does it make sense
that X belongs to Y and Z doesn't".  To me, such activity is like
"tagging" (assign a specific word belonging to a finite set of words),
it is usually a lot of effort and energy for, at the end, few, if not
none, pragmatic outcomes.

Last, for classification (assign a package to one module depending on
the affinity with the other packages of that module), well, it could
almost arbitrary (manual depending of human choice) as it is now or it
could be self-organized depending on the data themself. From my point
of view, it could be interesting to apply some kind of self-organized
map (SOM) and other related things.  It could be help for many other
issues as "search".  Pointers for what they are worth:

https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00252.html
https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00160.html


Cheers,
simon