ludo@gnu.org (Ludovic Courtès) writes:

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>>    ?: 2 [primitive-load "/gnu/store/d51z2xkwp1vh0dh6gqadyyzv21m0b772-guix-latest/guix/scripts/import/hackage.scm"]
>>> In ice-9/eval.scm:
>>>  453: 1 Exception thrown while printing backtrace:
>>> ERROR: In procedure package-location: Wrong type argument: Error while printing exception.
>>>
>>> ice-9/eval.scm:387:11: In procedure eval:
>>> ice-9/eval.scm:387:11: In procedure package-version: Wrong type argument: Error while printing exception.
>>> builder for `/gnu/store/pc1i5s6vx9yx97prhskx178gj5swxw4k-guix-latest.drv' failed with exit code 1
>>> guix pull: error: build failed: build of `/gnu/store/pc1i5s6vx9yx97prhskx178gj5swxw4k-guix-latest.drv' failed
>>>
>>> Any idea?
>>>
>>> To me it sounds like there are two <package> record type descriptors in
>>> the wild, which is why ‘package-location’ in the package record printer
>>> bails out.
>>
>> That's one of the errors that result from a "bad" order of compiling the
>> files and when the 'load' hack isn't used to work around it, which isn't
>> the case in that patch...  Indeed I can't seem to reproduce the issue.
>>
>> The attached patch below also builds on the quoted patch, removes the
>> thread-safe-port procedure, and just sets the warning port to a void
>> port.  Applied on top of the current master, it works for me.
>
> On top of current master, it fails for me in the same way as above.
>
> To be clear, I applied the patch, ran ‘make dist’, and then:
>
>   time ./pre-inst-env guix pull --url=file://$PWD/guix-0.9.0.tar.gz
>
> Are you doing the same?  The “loading” part is done sequentially, so it
> should be deterministic.

Whoops, I had not rerun the whole 'make dist' after rebasing on master,
only copied the new guix/build/pull.scm into an existing tarball (I had
gotten used to doing that because it saves time while working on a
single file), so changes in other files were missing.

After some tinkering around I realized that the problem is that our
workaround of loading files explicitly causes the package record type to
be redefined after some packages have already been defined.  More
generally, we force the top-level of many files to be re-executed after
they've already been executed as a result of a module import...

It would be great if the whole circular import problem could somehow be
solved by Guile (no idea how feasible it is).  On the meanwhile, we'll
have to work around problems introduced by workarounds. :-) Moving the
loading of guix/package.scm to the very front seems to solve the issue.
Other record types could still cause the same issue, but their relative
rarity of use hopefully makes this a non-issue.  I also moved the
loading of guix/ files before gnu/ files again, which might also help
with that.  (For package.scm it wasn't sufficient, probably because some
modules under guix/ import some gnu package modules, before package.scm
is loaded explicitly.)

One can imagine a wholly more robust version of the workaround, which
avoids the re-execution of top-levels.  A variant of load[-primitive]
that doesn't load a file again if it was already loaded would do.
That's basically what importing a module does, so scanning for module
definitions in files and importing them might work, but seems somewhat
hacky...  For now, here's the patch that just loads package.scm first.