[bug]: Wrong binary is downloaded on a mac for eza-community/eza instead of erroring

jankatins commented 1 year ago

What happened?

The ghr for eza-community/eza installs a windows binary on my (intel) mac.

https://github.com/eza-community/eza/releases/tag/v0.11.0 contains:

aarch64-unknown-linux-gnu-eza x86_64-pc-windows-gnu-eza.exe x86_64-unknown-linux-gnu-eza

So the real problem is that it wrongly tries to download something instead of erroring out as there is no relevant item to download :-(

(I also opened a upstream feature request to provide mac binaries, but I guess this part is still a zinit bug)

Steps to reproduce

.zshrc:

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'!**/eza' for @eza-community/eza

Relevant output

λ  exec zsh

Downloading eza-community/eza…

(Requesting `x86_64-pc-windows-gnu-eza.exe'…)
########################################################################################################################################################################### 100.0%
[ziextract] Unpacking the files from: `x86_64-pc-windows-gnu-eza.exe'…
chmod: --: No such file or directory
→zinit-extract:2: command not found: cygpath
→zinit-extract:2: exec format error: ./x86_64-pc-windows-gnu-eza.exe
[ziextract] Error: extraction of the archive `x86_64-pc-windows-gnu-eza.exe' had problems.

Operating System & Version

Zsh version

zsh 5.9 (x86_64-apple-darwin21.3.0)

Terminal emulator

xterm-256color (wezterm)

Code of Conduct

[X] I agree to follow this project's Code of Conduct

jankatins commented 1 year ago

And I wrote this exact issue report already a few month back: https://github.com/zdharma-continuum/zinit/issues/295 -> closing this one...

vladdoster commented 1 year ago

@jankatins,

I think this would be useful.

jankatins commented 8 months ago

Just FYI: still running into this...

λ  uname
Darwin

λ  exec zsh

==> Downloading eza-community/eza
==> Requesting eza.exe_x86_64-pc-windows-gnu.tar.gz
################### 100.0%
[ziextract] Unpacking the files from: `eza.exe_x86_64-pc-windows-gnu.tar.gz'…
[ziextract] Successfully extracted and assigned +x chmod to the file: eza.exe.
Error: linkbin: lbin ice (**/eza) did not match any files

jankatins commented 8 months ago

Another package: no mac binary in the github release, so it ends up with linux :-(

λ  exec zsh

==> Downloading aristocratos/btop
==> Requesting btop-x86_64-linux-musl.tbz
#################### 100.0%
[ziextract] Unpacking the files from: `btop-x86_64-linux-musl.tbz'…
[ziextract] Successfully extracted and marked 4 executable the appropriate files (btop, install.sh, setuid.sh, uninstall.sh) contained in `btop-x86_64-linux-musl.tbz'.
==> linkbin: Created btop soft link & set +x on the btop binary

λ  uname -o
Darwin

vladdoster commented 8 months ago

@jankatins

zinit tests hit the issue relatively often where the projects latest release assets lack a os/arch until the maintainer completes building them which can take days/weeks or maybe support changes, etc.

so, does zinit try older releases if no ver ice is specified or fail outright? because btop has a macos build in previous release.

jankatins commented 8 months ago

Personally I would like it to fail. https://github.com/zdharma-continuum/zinit/issues/295 has an idea how to make this more reliable (first removing "known not working" downloads and then apply the heuristic to the leftover downloads)

zdharma-continuum / zinit