<ngz>I'm trying to understand the difference between #:modules and #:imported-modules in a `package' reference. The manual doesn't say anything about it (there's something in `origin' references, so I guess this also applies to `package').
<ngz>Yet, the wording is subtle. For `modules': "should be loaded [...] while running the code in the `snippet.". For `imported-modules': "for use by the `snippet'".
<iyzsong>ngz: see the doc string of `gnu-build', `imported-modules' are for builder to know non-builtin Guile modules, while `modules' will be called as `(use-modules ,@modules)'.
<ngz>iyzsong: Thank you. However, the doc string is not very helpful: "Build from SOURCE to OUTPUTS, using INPUTS, and by running all of PHASES in order. Return #t if all the PHASES succeeded, #f otherwise."
<iyzsong>ngz: oh, I'm look at it in `guix/build-system/gnu.scm'..
<ngz>So anything with (guix ...) or (gnu ...) prefix should also be added to `imported-modules' since they are not provided by Guile itself. Is that correct?
<ngz>(as long as the provide a function used in the phase)
***isReKT2000 is now known as imrekt
***imrekt is now known as imr
<ajgrf>i'm packaging an emacs plugin right now, and a couple extra directories (.../guix.d/<package-name>/...) got inserted into the final package that i don't understand. anyone know what that's about?
<ajgrf>it seems to be something the emacs build system is doing for me, and i don't know if that's why my package doesn't work or if it's something else
<ajgrf>nevermind, emacs found the plugin fine after i closed and re-opened it
<alezost>ajgrf: it is correct: emacs-build-system put emacs packages into "guix.d" subdirectories
<sandro_>lfam: however, it seems not possible to chroot guix "under" another system (live or not) .... I use that "tecnique" to have under my eyes a new system and have all the possibility about communication using other software ... :|
<lfam>On GuixSD, there is /bin/sh. Otherwise, you have to do something like what pxc suggests.
<sandro_>pxc: thanx ... i've used the "classic" tecnique" to chroot a new OS;
<pxc>on NixOS it's /nix/current-system/sw/bin/bash or something like that. there's also an additional bootstrapping quirk having to do with the init process, for chrooting into NixOS. maybe GuixSD doesn't share the issue thanks to dmd
<sandro_>ok ... i go to eat my little "pizza" ... then i can tell You about positive news :)
<lfam>You might also find the `guix system vm` and `guix system vm-image` commands useful. They make it easy to create and run GuixSD QEMU images
<sandro_>I can also reboot guix and use hexchat ... but since my Funtoo has ~1800 ebuilds, i've the possibility to give a simpler feedback using various instructions.
<sandro_>however ... ok few minutes .. and i will restart in guix :P
<sandro__>adfeno ... yes :) in this irc i've learned to use lisp instead pastebin :)
<pxc>sandro__: I'm afraid I don't know Guix all that well because I'm not currently running it on any of my systems. Most of what I know about Guix I know through Nix, a sister project which was once the basis for Guix
<pxc>Nix and Guix are still superficially compatible (the nix daemon and the guix daemon are compatible, and they put things in the same locations except under Nix the store paths begin with /nix and under Guix they begin with /gnu)
<pxc>I plan to start using Guix when I can get it to share a store with my Nix install, but I haven't gotten around to it yet
<sandro__>pxc: Thanks To You for answers :) .... My first system for now is Funtoo (a Gentoo variant) but i'm very very interesting about guix :)
<sandro__>cause it seems an incredible system and can have a great future :P