unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Attila Lendvai <attila@lendvai.name>
To: guix-devel <guix-devel@gnu.org>
Subject: shepherd GEXP module import mystery
Date: Mon, 27 Nov 2023 22:52:51 +0000	[thread overview]
Message-ID: <OH7z__0HSHNJ1UF3n3y3a7Z11LwONNhdb3ZavIY0nir5XTcAwAA5I0ESOV5wxx9iNbz7MzEdsYKJNjrVlpIybscb-Tcjfa0b82SjdafaXwk=@lendvai.name> (raw)

dear Guix,

context: i'm adding logging to shepherd, and while i was testing it i encountered a conflict with my service code that shouldn't happen.

i'm probably missing something from my mental model around guile modules, and/or how shepherd compiles and loads them.

the symptom is that a start GEXP of my service sees bindings that come from the module called (shepherd support), but i have no idea who and where imports that module.

i added the following two format lines to the beginning of my start GEXP:

(format #t "*** start gexp speaking, current module is ~A, module-uses: ~A~%  ringbuffer: ~A~%"
  (current-module)
  (module-uses (current-module))
  (and=> (module-variable (current-module) 'ring-buffer) variable-ref))

(format #t "*** ringbuffer in packages: ~A~%"
  (map (lambda (module-name)
         (and=> (module-variable (resolve-interface module-name)
                                 'ringbuffer)
                variable-ref))
       '((guile) (oop goops) (shepherd service) (srfi srfi-34)
         (system repl error-handling) (guix build utils) (guix build syscalls)
         (gnu build file-systems))))

and they print:

*** start gexp speaking,
current module is #<module (#{ g108}#) 7f6a3af34be0>
module-uses: (
#<interface (guile) 7f6a3ade6dc0>
#<interface (oop goops) 7f6a399eac80>
#<interface (shepherd service) 7f6a39489a00>
#<interface (srfi srfi-34) 7f6a399ea8c0>
#<interface (system repl error-handling) 7f6a39489dc0>
#<custom-interface (guix build utils) 7f6a3af34140>
#<interface (guix build syscalls) 7f6a38cd6e60>
#<custom-interface (guix build utils) 7f6a38cd6500>
#<custom-interface (gnu build file-systems) 7f6a38d6a460>
#<interface (gnu system file-systems) 7f6a38d24b40>
#<custom-interface (guix build utils) 7f6a38d6a3c0>
#<custom-interface (gnu build file-systems) 7f6a38d6a320>
#<custom-interface (guix build utils) 7f6a38d6a280>
#<custom-interface (gnu build file-systems) 7f6a38d6a1e0>
#<custom-interface (guix build utils) 7f6a38d6a140>
#<custom-interface (gnu build file-systems) 7f6a38d6a0a0>
#<custom-interface (guix build utils) 7f6a38d6a000>
#<custom-interface (gnu build file-systems) 7f6a38d93f0

  ringbuffer: #<procedure ring-buffer (size)> 

*** ringbuffer in packages: (#f #f #f #f #f #f #f #f) 

how else can a definition (i.e. 'ringbuffer) get into this module without it coming from one of the modules in its module-uses list?

i'm pretty sure that it's coming from (shepherd support) because i'm neck deep in debugging the original issue: a macro from (shepherd support) overwrote my function that errored when it was called at runtime as a function.

i'm also seeing this warning (i.e. my root issue):

WARNING: (#{ g108}#): `log.debug' imported from both (guix-crypto utils) and (shepherd support)

i've checked the module list of the gexp, and how guix compiles the .go files that are then given to shepherd, and i see nothing obvious. i even looked at the source file that gets generated and compiled for the service in question, and it doesn't contain any mention of this module.

there are no direct mentions of (shepherd support) in the source, that's why i thought maybe something re-exports the entire module, so i checked the presence of 'ringbuffer in all the used modules... but it's not in any of them.

could it be a bug in how different versions/instances of guile serialize/load a .go file? or could it be due to the module magic in (gnu services shepherd) that compiles the shepherd config into a .go file?

i'm out of ideas, any hint is appreciated!

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“People always find partners [with] exactly the same level of unresolved traumas they are at, without any exception. Now the trauma may look differently, and how it manifests may look differently, but the degree of trauma is always equal, I mean with perfect accuracy. […] And that trauma then shows up in the relationship.”
	— Gábor Máté (1944–), 'On The Spot - Az ellenség gyermekei', 48m50s



             reply	other threads:[~2023-11-27 22:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27 22:52 Attila Lendvai [this message]
2023-11-27 23:30 ` shepherd GEXP module import mystery Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-11-28 12:16   ` Attila Lendvai
2023-12-05 21:38     ` Attila Lendvai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='OH7z__0HSHNJ1UF3n3y3a7Z11LwONNhdb3ZavIY0nir5XTcAwAA5I0ESOV5wxx9iNbz7MzEdsYKJNjrVlpIybscb-Tcjfa0b82SjdafaXwk=@lendvai.name' \
    --to=attila@lendvai.name \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).