Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug]: Commit d59f150 filters appimages from Github release assets #228

Closed
LarsHaalck opened this issue Apr 25, 2022 · 6 comments
Closed
Labels
bug Something isn't working

Comments

@LarsHaalck
Copy link

Describe the bug

Using bpick"*appimage*"no longer works as of d59f150 as can be seen here d59f15067eeeb97ac0695066115cf6abb46075e5/zinit-install.zsh#L1489

Steps to reproduce

zinit ice wait lucid from"gh-r" as"null" bpick"*appimage*" sbin"nvim* -> nvim" ver="stable"
zinit light neovim/neovim

Expected behavior

Prior to d59f150, the above command would select nvim.appimage. This is now filtered out, selecting nvim.appimage.zsync.

Screenshots and recordings

No response

OS / Linux distribution

Arch Linux (5.17.3)

Zsh version

5.8

Terminal emulator

Alacritty

If using WSL on Windows, which version of WSL

No response

Additional context

No response

@LarsHaalck LarsHaalck added the bug Something isn't working label Apr 25, 2022
@vladdoster
Copy link
Member

vladdoster commented Apr 25, 2022

You shouldn't need to use bpick anymore as the updates improved gh-r logic. Unless there is
a particular reason for using AppImage, try the following recipe:

zinit from'gh-r' sbin'**/nvim' ver'stable' for neovim/neovim

I don't think ver' ' ice would only be needed when wanting the nightly build, but not 100%.

@LarsHaalck
Copy link
Author

Ah yes you are right. I think I had to install the appimage on some older neovim version on a very old remote machine. Your recipe works fine for neovim thanks.

But if I understand the code correctly, on a project that has only a single appimage asset, it will be filtered out and there is no way for the user to bpick it manually right?

@vladdoster
Copy link
Member

Your hypothesis would be correct. But, given that App images are somewhat rare (from what I've seen) GitHub release assets, the odds of that are slim.

I perused the appimagehub and here are a handful of releases from a total of ~1300 projects

From what I've seen, AppImage has not received much love. My personal experience with them has always included some technical issues. Hard to get traction when there are established and proven pkg managers. And, IMO, goes against the unix philosophy ;).

@LarsHaalck
Copy link
Author

Thanks for the detailed explanations. I fully understand and I think for all my use cases, I can live without Appimages, but I think the user, nevertheless, should have to option to explicitly request it (e.g, to allow it as a last resort). But if this is the consensus and/or if has been discussed elsewhere, I think we can close this issue. Thanks.

@vladdoster
Copy link
Member

No problem :^)

@vladdoster
Copy link
Member

@LarsHaalck

There was an issue with the regex (unrelated to AppImages, however), and went ahead to include a fix to this issue. I also added tests to avoid future regressions.

See #244

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants