Christopher Baines <mail@cbaines.net> writes:

> Tanguy Le Carrour <tanguy@bioneland.org> writes:
>
>> Le 04/20, Christopher Baines a écrit :
>>> Tanguy Le Carrour <tanguy@bioneland.org> writes:
>>> > As I said, I'm still learning. But I've tried, and here is what I've
>>> > done so far […]
>>>
>>> I tried changing the inputs to native-inputs, and the package built for
>>> me. Could you share the exact changes you made?
>>
>> I haven't done much:
>>
>> --- a/gnu/packages/shellutils.scm
>> +++ b/gnu/packages/shellutils.scm
>> @@ -129,12 +129,11 @@ are already there.")
>>           ;; Help the build scripts find the Go language dependencies.
>>           (add-before 'unpack 'setup-go-environment
>>             (assoc-ref go:%standard-phases 'setup-go-environment)))))
>> -    (inputs
>> -     `(("go" ,go)
>> -       ("go-github-com-burntsushi-toml" ,go-github-com-burntsushi-toml)
>> -       ("go-github-com-direnv-go-dotenv" ,go-github-com-direnv-go-dotenv)))
>>      (native-inputs
>> -      `(("which" ,which)))
>> +      `(("go" ,go)
>> +        ("go-github-com-burntsushi-toml" ,go-github-com-burntsushi-toml)
>> +        ("go-github-com-direnv-go-dotenv" ,go-github-com-direnv-go-dotenv)
>> +        ("which" ,which)))
>>      (home-page "https://direnv.net/")
>>      (synopsis "Environment switcher for the shell")
>>      (description
>>
>>
>> Thanks again for your time!
>
> What you've put above looks ok, I'm unsure why that wouldn't work...

Just to follow up, as I've learned some more.

So... last night I had this same failure on another machine. Turns out
there is a bigger issue with the direnv package. The particular
combination of the 'setup-go-environment phase from the go-build-system,
and the 'unpack phase from the gnu-build-system, leads to
non-deterministic behaviour, where dependent on the order in which the
filesystem returns two directories, the package either builds, or fails
to build.

> I think it would be better to switch to using the go build system, and
> the package in Guix is quite a few versions behind.

As far as I understand, switching entirely to the go-build-system will
avoid this issue we've both now encountered, so I've sent a patch up
about this [1]. I've also created an issue to track the problem in the
gnu-build-system, as I think it could check for this circumstance and
error, to avoid this issue happening in the future.

1: https://issues.guix.info/issue/35386
2: https://issues.guix.info/issue/35387