IRC channel logs
2022-02-28.log
back to list of logs
<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?! <rekado>with ‘guix time-machine’ we launch and older Guix and just pass arguments to it. <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.