bug#33647: First `guix pull' behaves unexpectedly

["Ludovic Courtès" <ludo@gnu.org>]

Hi Diego,

Diego Nicola Barbato <dnbarbato@posteo.de> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Diego Nicola Barbato <dnbarbato@posteo.de> skribis:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>> [...]
>>
>>>> In addition, be aware that Bash maintains a cache of commands it looked
>>>> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
>>>> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
>>>> invalidate its cache thus you kept using that old version.
>>>>
>>>> The solution is to run “hash guix” at the Bash prompt to force cache
>>>> invalidation (info "(bash) Bourne Shell Builtins").
>>>
>>> I believe this is it.  This also explains why ‘which guix’ returned the
>>> updated guix while ‘guix --version’ claimed it was still the older
>>> version, which I found rather confusing.
>>> I am afraid being unaware of this has led me to inadvertently downgrade
>>> GuixSD whenever I reconfigured for the first time after a fresh install.
>>
>> Yeah.  This is not strictly speaking a Guix bug, but clearly it’s a
>> common pitfall.  Perhaps we should print a hint upon completion?
>
> While I think it would be nice for Guix (or strictly speaking Bash) to
> just do what a noob like me would expect it to do in this situation, a
> hint would have certainly saved me some trouble.  If it is unreasonably
> cumbersome to make Guix tell Bash to invalidate its cache upon
> completion of ‘guix pull’, I believe a hint would be good enough.

Thanks for the heads-up.  Commit
3bbd6919bd84b76686d1aa626ba861faf3fc8ceb changes ‘guix pull’ to display
a hint in this case.

Ludo’.