Open jankatins opened 1 year ago
This seems to be already a bug since November 2022: https://github.com/zdharma-continuum/zinit-annex-patch-dl/issues/6#issuecomment-1321357390
I debugged this a bit (BTW: a wiki doc on how to debug stuff would be much appreciated, I basically add prints until I find something interesting...):
Right before update, we see this hooks from dl annex:
print -l $ZINIT_EXTS
11 z-annex-data: zinit-annex-patch-dl hook:!atclone-20 za-patch-dl-handler za-patch-dl-help-null-handler dl''|patch''
12 z-annex-data: zinit-annex-patch-dl hook:!atpull-20 za-patch-dl-handler za-patch-dl-help-null-handler ''
There is a difference in the lines and funnily, if I change my zinit call to include a atpull"%atclone"
(despite no atclone
ice!), an update does the right thing:
λ zinit light-mode depth"1" for \
@zdharma-continuum/zinit-annex-binary-symlink \
@zdharma-continuum/zinit-annex-bin-gem-node \
@zdharma-continuum/zinit-annex-default-ice \
@zdharma-continuum/zinit-annex-patch-dl \
@zdharma-continuum/zinit-annex-readurl
λ zinit default-ice --quiet as'null' from"gh-r" lbin'!' lucid nocompile completions
λ zinit lbin'!' atpull"%atclone" completions \
dl'https://raw.githubusercontent.com/junegunn/fzf/master/bin/fzf-tmux;
https://raw.githubusercontent.com/junegunn/fzf/master/shell/completion.zsh -> _fzf_completion;
https://raw.githubusercontent.com/junegunn/fzf/master/shell/key-bindings.zsh;
https://raw.githubusercontent.com/junegunn/fzf/master/man/man1/fzf-tmux.1 -> $ZPFX/man/man1/fzf-tmux.1;
https://raw.githubusercontent.com/junegunn/fzf/master/man/man1/fzf.1 -> $ZPFX/man/man1/fzf.1' \
src"key-bindings.zsh" \
for @junegunn/fzf
λ rm ~/.local/share/zinit/plugins/junegunn---fzf/._zinit/is_release
λ zinit update junegunn/fzf
(Requesting `fzf-0.38.0-darwin_amd64.zip', version 0.38.0…)
########################################################################################################################################################################### 100.0%
[ziextract] Unpacking the files from: `fzf-0.38.0-darwin_amd64.zip'…
Archive: fzf-0.38.0-darwin_amd64.zip
inflating: fzf
[ziextract] Successfully extracted and assigned +x chmod to the file: fzf.
Installed 0 completions. They are stored in the $INSTALLED_COMPS array.
Skipped installing 1 completions. They are stored in the $SKIPPED_COMPS array.
[patch-dl annex] fzf-tmux downloaded successfully
[patch-dl annex] _fzf_completion downloaded successfully
[patch-dl annex] key-bindings.zsh downloaded successfully
[patch-dl annex] fzf-tmux.1 downloaded successfully
[patch-dl annex] fzf.1 downloaded successfully
[linkbin annex] Re-created the fzf soft link and set +x on the fzf binary
-> So this seems to be a bug in the annex not registering the right command for the hook?
Ok, seems there is multiple things and some of them are on the zinit side:
The registering in the patch-dl repo:
@zinit-register-annex "zinit-annex-patch-dl" \
hook:\!atpull-20 \
za-patch-dl-handler \
za-patch-dl-help-null-handler
As the above, that works, it's in $ZINIT_EXTS
My understanding is that the following line(s) should return the hook which got registered in for the dl annex (from the middle part of that "thing"):
reply=(
${(on)ZINIT_EXTS2[(I)zinit hook:e-\!atpull-pre <->]}
${${(M)ICE[atpull]#\!}:+${(on)ZINIT_EXTS[(I)z-annex hook:\!atpull-<-> <->]}}
${(on)ZINIT_EXTS2[(I)zinit hook:e-\!atpull-post <->]}
)
There are multiple things here:
a) the line ${${(M)ICE[atpull]#\!}:+${(on)ZINIT_EXTS[(I)z-annex hook:\!atpull-<-> <->]}}
returns nothing, but the second part should (and does!) return the registered hook:
λ echo ${${(M)ICE[atpull]#\!}:+${(on)ZINIT_EXTS[(I)z-annex hook:\!atpull-<-> <->]}}
λ echo ${(on)ZINIT_EXTS[(I)z-annex hook:\!atpull-<-> <->]}
z-annex hook:!atpull-20 12
λ echo ${(M)ICE[atpull]#\!}
the "12" entry is 12 z-annex-data: zinit-annex-patch-dl hook:!atpull-20 za-patch-dl-handler za-patch-dl-help-null-handler ''
-> the dl-patch function.
b) Even if that line would return the hook, it would run before the actual gh-r download which is registered as @zinit-register-hook "atpull'!'" hook:e-\!atpull-post ∞zinit-atpull-e-hook
, so gets returned by ${(on)ZINIT_EXTS2[(I)zinit hook:e-\!atpull-post <->]}
. For install it's the reverse: the gh-r download is first, the dl lines second.
So and here I'm stuck: I've no clue what the intend of the ${${(M)ICE[atpull]#\!}:+${(on)ZINIT_EXTS[(I)z-annex hook:\!atpull-<-> <->]}}
line is: why should there an hook in the ICE variable: it should contain a "atpull" ice (not a hook) from the saved ices. But I anyway have no atpull. And why isn't it overwritten by the ZINIT_EXTS stuff?
-> I'm out for now, I will just add the atpull'%atclone'
and call it a day for now...
Actually, one fix would be to change the hook registering to
@zinit-register-annex "zinit-annex-patch-dl" \
hook:atpull-20 \
za-patch-dl-handler \
za-patch-dl-help-null-handler
-> without exclamation mark, so runs after the pull!
It works, because the post pull hooks are looked up without looking at the ICE one:
reply=(
${(on)ZINIT_EXTS2[(I)zinit hook:atpull-pre <->]}
${(on)ZINIT_EXTS[(I)z-annex hook:atpull-<-> <->]}
${(on)ZINIT_EXTS2[(I)zinit hook:atpull-post <->]}
)
Nevertheless:
it seems there is no way for a annex to contribute hook which is run before the ghr download.
There is a PR which fixes the original problem, but there is still a bug here if you want to register a hook from an annex to be run before gtit pull/gh-r download happens.
@jankatins,
Circling back on this issue to see if this issue can be closed?
Additionally, +1 for thoroughly documenting the what & why of the issue & fix.
No, basically no hook for hook:\!atpull-*
works (update: unless the zinit call has a atpull ice? I still don't really understand that line...), that problem is at the zinit side and needs a fix. The easiest would be to use the same pattern as for hook:atpull-*
(without exclamation mark), but i have no idea why that was actually used/built in. Does anyone still know?
No, basically no hook for
hook:\!atpull-*
works, that problem is at the zinit side and needs a fix. The easiest would be to use the same pattern as forhook:atpull-*
(without exclamation mark), but i have no idea why that was actually used/built in. Did anyone still know?
@psprint,
Could you shed some light on the aforementioned design choice for @jankatins and I?
I guess this is the original commit which introduced this: https://github.com/zdharma-continuum/zinit/commit/dd51c6e960ef9d0a66792245cfe936931d4cc51f and this is what converted it to the current form: https://github.com/zdharma-continuum/zinit/commit/4236d9769ec87edf58bd86dd9b79a951cd8e3e09
Both of these are above my level of understanding of zsh code to understand the intend of what these lines should do... :-/
Interestingly, all atclone
hook calls are done without looking at the ice content -> another argument to simply remove that part?
Afair the !hook is run on atclone'!...' ice, without it's run on atclone'...'. if the problem is with exclamation mark then you can switch to some other char, like x (xatclone).
Status: The "problem" was worked around by changing the patch annex to hook into a different place, but the underlying problem is still there (from https://github.com/zdharma-continuum/zinit/issues/467#issuecomment-1464989941):
basically no hook for hook:!atpull- works (update: unless the zinit call has a atpull ice? I still don't really understand that line...), that problem is at the zinit side and needs a fix. The easiest would be to use the same pattern as for hook:atpull- (without exclamation mark), but i have no idea why that was actually used/built in. Does anyone still know?
Old issue
What happened?
I'Ve the following recipe for fzf:
Recently, it seems fzf got an update and it now does not have the files which should be downloaded via the patch-dl annex. They are there after a fresh install.
Steps to reproduce
zinit update
<plugin dir>/._zinit/
dir so zinit thinks it has an old versionzinit update junegunn/fzf
-> nopatch-dl annex
lines are shownls -la ~/.local/share/zinit/plugins/junegunn---fzf/
-> observe that the dl files are missingzinit delete -y junegunn/fzf && exec zsh
-> observe that thepatch-dl annex
linesls -la ~/.local/share/zinit/plugins/junegunn---fzf/
-> the dl ice files are thereRelevant output
Screenshots and recordings
No response
Operating System & Version
OS: darwin21.3.0 | Vendor: apple | Machine: x86_64 | CPU: x86_64 | Processor: i386 | Hardware: x86_64
Zsh version
zsh 5.9 (x86_64-apple-darwin21.3.0)
Terminal emulator
xterm-256color (wezterm)
If using WSL on Windows, which version of WSL
None
Additional context
No response
Code of Conduct