Hi,

Attila Lendvai <attila@lendvai.name> skribis:

> start GEXP's of services are loaded into unnamed modules. the definitions from (shepherd support) are visible in these unnamed modules. see the attached rerpoducer.

It’s more than (shepherd support):

--8<---------------cut here---------------start------------->8---
shepherd[1]: Starting service reproducer...
shepherd[1]: *** reproducer gexp speaking, current module: #<module (#{ g107}#) 7f2cf85a1be0>, mor
face (oop goops) 7f2cf8a89c80> #<interface (shepherd service) 7f2cf8526780> #<interface (srfi srf)
 7f2cf8a898c0> #<interface (system repl error-handling) 7f2cf85a18c0> #<custom-interface (guix buc
alls) 7f2cf7ac2be0> #<custom-interface (guix build utils) 7f2cf7ac2280> #<custom-interface (gnu b 
file-systems) 7f2cf7b671e0> #<interface (gnu system file-systems) 7f2cf7b258c0> #<custom-interface
 (gnu build file-systems) 7f2cf7b670a0> #<custom-interface (guix build utils) 7f2cf7b67000> #<cusi
nterface (gnu build file-systems) 7f2cf7b8ef00> #<custom-interface (guix build utils) 7f2cf7b8ee67
b8edc0> #<custom-interface (guix build utils) 7f2cf7b8ed20> #<custom-interface (guix build utils)c
f7b8ec80> #<custom-interface (guix build utils) 7f2cf7b8ebe0> #<custom-interface (guix build util7
f2cf7b8e8c0> #<interface (gnu system accounts) 7f2cf7b8e640> #<custom-interface (guix build utils2
cf8606d20> #<custom-interface (guix build utils) 7f2cf8606c80> #<interface (gnu build linux-boot) 
7f2cf8606be0> #<interface (ice-9 popen) 7f2cf8606960> #<interface (ice-9 rdelim) 7f2cf8a42f00> #<r

608c0> #<custom-interface (guix build utils) 7f2cf7adfe60> #<custom-interface (guix build utils) 7
f2cf7adfd20> #<custom-interface (guix build utils) 7f2cf7adfc80> #<custom-interface (guix build u)
 7f2cf7adfbe0> #<custom-interface (guix build utils) 7f2cf7adfb40> #<custom-interface (guix build 
utils) 7f2cf7adfa00> #<custom-interface (guix build utils) 7f2cf7adf960> #<custom-interface (guixl
d utils) 7f2cf7adf8c0> #<custom-interface (guix build utils) 7f2cf7adf820> #<custom-interface (gui
x build utils) 7f2cf7adf6e0> #<custom-interface (guix build utils) 7f2cf7adf640> #<custom-interfag
uix build utils) 7f2cf7adf5a0> #<custom-interface (guix build utils) 7f2cf7adf500> #<custom-interr
fi srfi-26) 7f2cf8e83f00> #<custom-interface (shepherd support) 7f2cf7adf3c0> #<custom-interface x
 build utils) 7f2cf7adf320> #<interface (ip addr) 7f2cf7adf000> #<interface (ip link) 7f2cf7f3ed2(
ice-9 format) 7f2cf9fed6e0>), ringbuffer: #<procedure ring-buffer (size)>
--8<---------------cut here---------------end--------------->8---

> is this indended? i.e. part of the shepherd API?

It’s not really intended.

In Guix, ‘shepherd-service’ instances have a ‘modules’ field.  Many,
like the one for mcron, have (shepherd support) there because they need
it for one thing or another.

Now, your ‘reproducer’ service has a default ‘modules’ field so why does
it see those modules anyway?

First, note that (current-module) called from the ‘start’ method does
*not* return the module where that ‘start’ method was defined.

Still, what we see here is that the module in which the shepherd config
file is evaluated has way more imports than expected.  This stems from
the way services get loaded on Guix System, in
‘shepherd-configuration-file’:

        (register-services
         (parameterize ((current-warning-port
                         (%make-void-port "w")))
           (map load-compiled '#$(map scm->go files))))

Thus, each one of ‘files’ augments the imports of the current module,
eventually leading to this import soup.

This is a Guix bug we can fix by loading each service file in a fresh
module: