[Top][All Lists]

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

Re: Problem with texlive-default-updmap.cfg

From: Ricardo Wurmus
Subject: Re: Problem with texlive-default-updmap.cfg
Date: Wed, 30 Mar 2022 14:32:53 +0200
User-agent: mu4e 1.6.10; emacs 28.0.50

Hi again Ontje,

my apologies for taking so long to get back to you.

> if I try to run this hello world workflow, I get the following error:
> process hi
>   # { echo "hi" }
> workflow do-the-thing
>   processes hi
> $ 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?

Commit 2afadeea66e01f6d78e01eee910d2868f27531b8 works around this
problem by not sharing the same Guile process that was used to launch
“guix workflow”.

The first thing we do when the GWL extension is launched is to replace
the Guile load path.  We do this to ensure that the GWL uses the very
same Guix at runtime as the Guix we used to develop it.  This avoids a
lot of potential problems on users’ machines, where arbitrary versions
of Guix would be installed.  To avoid subtle breakage we just use a
well-known version of Guix as a library — and we use the “invoking Guix”
in an inferior to look up packages, so that users get the packages that
they expect.

Unfortunately, this doesn’t actually work as intended.  By the time
“guix workflow” is evaluated the Guile process will have already loaded
some of the Guile modules of the invoking Guix.  Replacing the load path
at that point does not have the intended effect because only those
modules we load *then* will belong to the well-known version of Guix —
whatever may have been loaded between “guix” starting and the moment
the “workflow” sub-command is invoked remains.

So to avoid “contamination” we now launch a new Guile process with a
well-known load path.  It’s not the prettiest solution, but it works
around the problem effectively.  It is a matter of philosophical debate
whether the GWL can still be called an “extension” to Guix when we
aren’t even using the same process and launch an independent Guile
process, but I’m okay with that because the exploration of this space is
one of the goals of the GWL :)


reply via email to

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