guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 01/01: services: Add SRFI-26 to Nix activation gexp.


From: Ludovic Courtès
Subject: Re: 01/01: services: Add SRFI-26 to Nix activation gexp.
Date: Thu, 13 Jun 2019 10:08:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi Tobias,

Tobias Geerinckx-Rice <address@hidden> 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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]