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

[Liliana Marie Prikler]

Am Donnerstag, dem 24.03.2022 um 19:07 +0100 schrieb Maxime Devos:
> zimoun schreef op do 24-03-2022 om 17:58 [+0100]:
> > I agree that lazyness is a good thing and a good direction. 
> > However, let be pragmatic with what we have now. :-)  What are the
> > performance comparison between breaking many cycles as Maxime is
> > proposing vs using many 'module-ref' + 'resolve-interface' instead
> > of break?
> 
> Currently this patch series does not improve anything much, according
> to "guix graph --type=module hello | wc --lines".  I'm now
> introducing some module-ref+resolve-interface --- it's very
> convenient, but I'm not yet at a significant result.
For the record, my suggestion to declare lazily loaded modules near the
top is based on the fact that Maxime's current patch set uses them to
break up cycles in a manner that also requires a comment in the define-
module clause for the sake of clarity.  As a nice side effect, it makes
it so that two-liners in the inputs field become one-liners.

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.

Btw. regarding style, I think declaring a function @PACKAGE_MODULE,
i.e. a literal '@ followed by the last symbol in the module's name,
would be the easiest, as one could read (@PACKAGE_MODULE arg) as a
shorthand for (@ (gnu packages PACKAGE_MODULE) arg).  Somewhat off-
topic, what's the rationale behind not using @ syntax?  Does @ have
different semantics from resolve-interface + module-ref?

Cheers