IRC channel logs


back to list of logs

<rekado>zimoun: getting better :)
<rekado>good enough to look at the GWL bug
<rekado>I’ve been looking at the difference between (%search-load-path "guix/profiles.scm") and (module-ref (resolve-interface '(guix profiles)) '%default-profile-hooks)
<rekado>the former returns the correct file: it corresponds to the old ‘library Guix’.
<rekado>but the second expression gets a value from a more recent Guix
<rekado>even though it’s not on the load path
<rekado>the load path has been restricted to a directory from a ‘guix shell’ output, which only contains the ’library Guix’ files.
<rekado>the guix/profiles.scm on the load path does not have the texlive-font-maps profile hook.
<rekado>so at some point — I don’t know where or why — some other Guix files are being used, even though they are not on the load path.
<rekado>there are two problems, one remains even if this is fixed: even though I’m building profile derivations in an inferior the profile *hooks* would come from the ’library Guix’, which may be wrong.
<rekado>currently I have the opposite unexpected problem, namely that the hooks come from a more *recent* Guix
<rekado>in any case: this is all wrong. I think I need to ensure that building in an inferior always also uses the profile hooks from that inferior.
<rekado>otherwise there’s going to be potential for broken profile builds.
<rekado>using an inferior is *not* like using ‘guix time-machine’
<rekado>looks like the use case of ‘guix as a library’ falls apart here.
<rekado>perhaps the inferior mechanism would need to change profile derivations such that the default hooks *also* come from the inferior.
<zimoun>rekado: thanks for the explanations. I am confused by «using an inferior is *not* like using ‘guix time-machine’»… Hum?!
*zimoun is thinking...
<rekado>with ‘guix time-machine’ we launch and older Guix and just pass arguments to it.
<rekado>it’s self-contained
<rekado>with an inferior on the other hand we can look up *packages* in a different Guix but at the same time also use *incompatible* library features, such as profile hooks.
<rekado>say I declaratively build a <profile> value with (profile (contents manifest)) with the Guix library, and then I make Guix build this in an inferior
<rekado>that profile will have the default hooks, which are (@ (guix profiles) %default-profile-hooks)
<rekado>these would correspond to the Guix that builds the <profile> value — and *not* the inferior where the profile is built.
<rekado>so when I do (run-with-store (inferior-store) (mlet* %store-monad ((drv (lower-object profile))) …)) then the profile hooks of that <profile> value may actually be incompatible with the packages available in inferior-store
<rekado>this is where the inferior abstraction falls apart; to avoid this I’d have to define the <profile> value with an inferior in mind and provide a compatible list of profile hooks.
<zimoun>aaahh! Yeah it makes sense. Thanks! Now, it remembers me some past discussions we had on gwl-devel; about who run what and how with all this dance. :-)
<rekado>I’m hoping that I can at least sidestep the issue by changing the profile hook to look up packages only in the profile manifest
<rekado>with texlive-default-updmap.cfg this doesn’t work directly, because it’s never installed, but that could be changed, of course
<rekado>this means that profile hooks may never use module-ref or risk breaking profile building in an inferior.
<zimoun>yes, I understand… that’s a really interesting use-case for inferiors mechaism.