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

From: Liliana Marie Prikler <[email-masked]>
Date: Thu, 24 Mar 2022 08:22:09 +0100

Hi Maxime,

Am Mittwoch, dem 23.03.2022 um 19:49 +0100 schrieb Maxime Devos:
> Maxime Devos schreef op wo 23-03-2022 om 19:46 [+0100]:
> > Import cycles make some packaging things harder and prevent some
> > proposed optimisations to "guix pull", let's start eliminating
> > them.
> > TBC ...
> 
> The copyright lines are based on a mix of "git blame" and "git log --
> grep the-package"; I might have missed some people ...
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.

I'm not sure if Guile's #:autoload could do anything to fix these
issues (I suppose not), but long term I think guile modules should
support a style that is basically (resolve-interface) + (module-ref) in
the manner Guix needs, but declaratively.  While we do not have that in
place yet, I suggest something like the following:

(define (check-package-ref pkg)
  (module-ref (resolve-interface '(gnu packages check)) pkg))
...

or 

(define check-package-ref
  (let ((iface (resolve-interface '(gnu packages check))))
    (lambda (pkg) (resolve-interface iface pkg))))

I'm not sure if the second will have the intended effect.  It appears
to me as though the key to breaking these cycles is moving them into a
context that is not evaluated on the top of the file, e.g. a thunked
field or in the case of my first suggestion a procedure.

In either case, declaring all these lazy dependencies near the module
definition would have the added benefit, that people could see them
being lazily imported and thus no longer need the #:use-modules
comment.

WDYT?