[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37586: Import cycles in unrelated packages should not be an error

From: Ludovic Courtès
Subject: bug#37586: Import cycles in unrelated packages should not be an error
Date: Sun, 06 Oct 2019 12:00:27 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi Florian,

"pelzflorian (Florian Pelz)" <address@hidden> skribis:

> 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.

> 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)


  (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.

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]