Re: Problem with texlive-default-updmap.cfg

[Ricardo Wurmus <rekado@elephly.net>]

Hi again,

I’m brazenly Cc-ing Ludovic, who understands the (guix inferior)
mechanism better than anyone else.

Too much information follows.

>> $ guix workflow run workflow.w
>> info: .19 Loading workflow file `workflow.w'...
>> info: .21 Computing workflow `do-the-thing'...
>> error: 3.33 No variable named texlive-default-updmap.cfg in #<interface (gnu packages tex) 7f3ed7185d20>
>>
>> Is something borked in my setup?
>
> Maybe.  Guix commit 805af862c6f0f6c54b74125bff8d348ae8f8e6f8 added
> texlive-default-updmap.cfg to the (gnu packages tex) module in question.

Looks like a genuine bug.  I haven’t quite figured out why it happens
yet, but it happens when the invoking Guix is recent enough to include
commit 805af862c6f0f6c54b74125bff8d348ae8f8e6f8.

That commit not only adds texlive-default-updmap.cfg to (gnu packages
tex), but also references it in (guix profiles).

With the GWL there really are always two versions of Guix: an older
fixed version of Guix that provides the Guile APIs that the GWL uses (=
Guix as a library) and whichever version of Guix the user used to invoke
“guix workflow” (= the invoking Guix).

We’re making an effort to capture the Guile load path at configure/build
time and then reset it to that known value at runtime when “guix
workflow” is invoked.  We do this so that the Guix library we used when
developing is the same Guix that is available at run time.

The invoking Guix on the other hand should always be what the user
expects.  It is used through (guix inferior) only.

This error indicates to me that a *new* Guix (e.g. the invoking Guix)
somehow ends up accessing an *old* Guix (e.g. the library Guix).  My
thinking is that the invoking Guix is asked to build a profile, then
builds the profile hook for TeX Live packages, and then somehow looks
*outside* of the invoking Guix for that package.

The profile hook does perform a lazy package lookup with this:

(define updmap.cfg
    (module-ref (resolve-interface '(gnu packages tex))
                'texlive-default-updmap.cfg))

I wonder if that ends up being evaluated outside of the inferior
somehow.  That would be quite a bummer.

I see one bad workaround: remove some/all profile hooks in the GWL.
This would likely circumvent this problem.

-- 
Ricardo