Hi, Below, a reply to Tomas. :-)
On Fri, 19 Jun 2026 at 19:11, Ludovic Courtès <[email protected]> wrote: >> It looks ok, it would be cleaner to have a single source to maintain >> but if the carry over can be automatized (I believe it could), it >> shouldn't be a lot of effort. Why changing the module name though? > > Maybe to avoid confusion and/or incompatibilities? Support (guix > records) evolves in incompatible ways that are okay for Guix and not > okay for other uses. > > Maybe it’s a fine detail though. Maybe let’s just start with (guix > records) imported as-is and we’ll see. About the name change, I’m not too worry with the potential confusion and/or incompatibilities > I’m fine with the migration, what about others in the “owners” team? I’m not in the “owners” team but I’m fine the migration and it appears to me nice! Cheers, simon Hi Tomas, On Sat, 20 Jun 2026 at 00:20, Tomas Volf <[email protected]> wrote: > The name change seems like a wise idea. It would be somewhat > frustrating for `guix' command to behave differently based on whether > this hypothetical guile-guix-records is installed in my home profile. No worry, because I don’t think it’s possible since the Guile module paths are hard-coded inside the Guix bash wrapper. --8<---------------cut here---------------start------------->8--- $ cat $(type -P guix) #!/gnu/store/f75z9sgss74ndiy1jnr02fippk1fjwkj-guile-wrapper/bin/guile --no-auto-compile !# (begin (set! %load-extensions (quote (".scm"))) (set! %load-path (append (list (string-append "/gnu/store/1xkz2ywjfb2b7zyyg3va0f0dp6z0x7bn-guix-module-union" "/share/guile/site/" (effective-version)) (string-append "/gnu/store/8vwbdsni9znrlxvcwqi4n02f23ysc1fa-guile-3.0.11" "/share/guile/" (effective-version))) %load-path)) (set! %load-compiled-path (append (list (string-append "/gnu/store/1xkz2ywjfb2b7zyyg3va0f0dp6z0x7bn-guix-module-union" "/lib/guile/" (effective-version) "/site-ccache") (string-append "/gnu/store/8vwbdsni9znrlxvcwqi4n02f23ysc1fa-guile-3.0.11" "/lib/guile/" (effective-version) "/ccache")) %load-compiled-path)) (let ((locpath (getenv "GUIX_LOCPATH"))) (setenv "GUIX_LOCPATH" (string-append (if locpath (string-append locpath ":") "") "/gnu/store/drapg7ap0g0n2hilibvrp9snhplrb0zx-glibc-utf8-locales-2.41/lib/locale"))) (let ((guix-main (module-ref (resolve-interface (quote (guix ui))) (quote guix-main)))) (begin (bindtextdomain "guix" "/gnu/store/mwsccn3gqjkycsfklpb0jr8lc01zfcj5-guix-locale-guix") (bindtextdomain "guix-packages" "/gnu/store/fapyk7pf0s5k84vf73nxh47m024z56my-guix-locale-guix-packages")) (apply guix-main (command-line)))) --8<---------------cut here---------------end--------------->8--- > I might simply not understand the module system well enough, so if Guix > gets "its" version, and applications using the dedicated package get > that version, all is fine. But I *think* it does not work like that and > the module name space is effectively global (first on search path > wins?). When building Guix via “guix pull”, then there is no issue because the potential clash would be resolved by hand as with any other dependencies (as with any other packages). The current incompatibilities of (guix records) are mainly internals incompatibilities and that are easily managed since the module is only for Guix consumption. Having (guix records) as a library implies to take care of other than Guix internal use-cases. That’s said, there is a kind of promise that Guix API as a Scheme library is stable enough, so let’s start the proposal. :-)
