Hi Ludo,

thanks for the answer :)

Ludovic Courtès <[email protected]> writes:

> Tomas Volf <[email protected]> skribis:
>
>> Some time back, Guix package switched to 3.0.11 (guile-3.0-latest), yet
>> guile-3.0 variable still points to 3.0.9.  I was installing guile-3.0
>> into my home, and `guile' REPL did not even start (I load guix in my
>> .guile).  Ludovic suggested (in #80671) to use guile-3.0-latest, which I
>> did, and that solved that particular problem.
>>
>> However, more problems showed up, and I need help thinking this through.
>
> Traditionally, ‘guix’ would depend on ‘guile-3.0-latest’ rather than
> ‘guile-3.0’, which “contaminates” all dependents.

Now that I think about it, is that good idea?  Should Guix package be
instead updated last, exactly in order not to have this effect on
dependents?

> For this reason, dependents use this trick to be in sync:
>
>     (native-inputs
>      (list …
>            (lookup-package-native-input guix "guile")))
>
> The thing to keep in mind is that Guile-generated bytecode is
> backward-compatible, but not forward-compatible.

Right, so I will also need to transform shepherd using the above in
order to be able to use module (built using the pattern above) inside
shepherd services, correct?

> HTH!

Yeah, the above is a neat trick, thank you.  As far as I understand I
should basically just replace

    (program-file "foo" #~(...))

in my configuration with

    (program-file "foo" #~(...)
                  #:guile (lookup-package-native-input guix "guile"))

it is bit verbose, but should ensure I will not have to change this
again.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Reply via email to