Hi Tobias, Tobias Geerinckx-Rice <[email protected]> skribis:
> Ludovic Courtès wrote: >> (srfi srfi-26) must not be added to the imported modules: it would >> import it from the host Guile, but the host Guile version may differ >> between users > > I looked at ‘G-Expressions’ in the manual before but I didn't see this > documented. Did I miss it, or is this tribal knowledge? I’m afraid it’s tribal knowledge. ;-) > Assuming there's at least a probably-good and definitely-bad set of > modules that should(n't) be imported this way: can we at least print a > warning when a non-(guix) module is listed, or whatever the rule would > be? Should we print a warning? I don’t know. ‘with-imported-modules’ does what it says: it imports modules from the host side into the build side. Usually, it’s “wrong” to import modules that ship with Guile, but there might be cases where you want to do it. So I’m not sure a warning is the right thing, but I’m open to suggestions! >> , and thus the resulting derivation would also differ. > > Just to make sure I follow, it's obviously wrong it both cases: this > would only be exposed if Guile's CUT suddenly changed its *behaviour* > in a visible (and likely very unintentional) way, right? Or does > with-imported-modules pull in (and hash) the actual object code > (/closure)? ‘with-imported-modules’ takes the srfi-26.scm file that you have in your %load-path, and makes it an input of the derivation. Between Guile 2.2.4 and Guile 2.2.5, the API is undoubtedly the same, but the file itself could be slightly different (for example, copyright years in the header might have changed.) Thus, if I run 2.2.5 and you run 2.2.4, we’d be getting different derivations, simply because our copy of srfi-26.scm differs. >> The right thing is to just (use-modules (srfi srfi-26)), which has >> the >> effect of using that module from the Guile being used for builds. >> >> Could you adjust it accordingly? > > Please take a second to check whether 79d19d7d does what you meant. It does, thank you! Ludo’.
