Import cycles in unrelated packages should not be an error

  • Open
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
pelzflorian (Florian Pelz)
Severity
normal
P
P
pelzflorian (Florian Pelz) wrote on 2 Oct 2019 19:15
(address . bug-guix@gnu.org)
20191002171547.ncb2hmujdwoxtquy@pelzflorian.localdomain
I am annoyed by another import cycle similar to
https://issues.guix.info/issue/37346 in an unfinished package I’m
writing. They needlessly complicate packaging and make packagers
split modules that logically should not be split.

Is it possible to make import cycles not an error in Guix packages?

These errors do not surface during module compilation but only when
running guix show or guix build or similar. I suppose that means
changing the way they are evaluated could make packages not care about
dependencies in unrelated packages that just happen to be in the same
module, could it?

Regards,
Florian
L
L
Ludovic Courtès wrote on 6 Oct 2019 12:00
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 37586@debbugs.gnu.org)
877e5ifb2c.fsf@gnu.org
Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (5 lines)
> I am annoyed by another import cycle similar to
> <https://issues.guix.info/issue/37346> in an unfinished package I’m
> writing. They needlessly complicate packaging and make packagers
> split modules that logically should not be split.

I agree that this is annoying.

Toggle quote (2 lines)
> Is it possible to make import cycles not an error in Guix packages?

Unfortunately no, it’s fundamentally impossible. When you have:

(define-module (a) #:use-module (b))
(define-public var-a 42)

and:

(define-module (b) #:use-module (a))
(define-public var-b (+ var-a 1))

you can understand that it will or will not work depending on whether
(b) or (a) is loaded first. This is what’s happening here.

Toggle quote (6 lines)
> These errors do not surface during module compilation but only when
> running guix show or guix build or similar. I suppose that means
> changing the way they are evaluated could make packages not care about
> dependencies in unrelated packages that just happen to be in the same
> module, could it?

When you use ‘guix show’ or similar, that goes through the package cache
created during ‘guix pull’, which allows Guix to load directly the
module that contains the package. That order could be different from
the one you have in your checkout.

Thanks,
Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 6 Oct 2019 12:40
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37586@debbugs.gnu.org)
20191006104014.oumwicescs7w3fe7@pelzflorian.localdomain
On Sun, Oct 06, 2019 at 12:00:27PM +0200, Ludovic Courtès wrote:
Toggle quote (22 lines)
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> > Is it possible to make import cycles not an error in Guix packages?
>
> Unfortunately no, it’s fundamentally impossible. When you have:
>
> (define-module (a) #:use-module (b))
> (define-public var-a 42)
>
> and:
>
> (define-module (b) #:use-module (a))
> (define-public var-b (+ var-a 1))
>
> you can understand that it will or will not work depending on whether
> (b) or (a) is loaded first. This is what’s happening here.
> […]
> When you use ‘guix show’ or similar, that goes through the package cache
> created during ‘guix pull’, which allows Guix to load directly the
> module that contains the package. That order could be different from
> the one you have in your checkout.
>

Thank you for the explanation. I now understand that eliminating the
error is not possible within define-module. Currently, all packages
rely on define-module’s “global” #:use-module form. How about adding
an alternative per-package, “local” use-module, to load and unload the
dependent module just for this one package? It appears to be
preferrable to splitting modules. Is it worth it?

Regards,
Florian
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 37586@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 37586
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch