Closed mustaqimM closed 2 years ago
Have you had a chance to look at the documentation? This is almost certainly not a bug.
Also, what command(s) are you using to update plugins?
Does that recipe work? I've modified it for macOS, but it doesn't seem to work?
it can be rewritten:
zi from'gh-r' nocompile sbin'*->rust-analyzer' for \
rust-lang/rust-analyzer
I use zi update -p
Thank you for that, I'll have to wait for the next Nightly to see. My one does work, as in it downloads the latest version, but if a newer version appears (Nightly or Stable), it doesn't update to it.
I also had to specify in my one bpick"*linux-gnu.gz"
since it downloaded the musl version. With your recipe, it tried the vsix
version.
I also had another problem with your recipe, *
doesn't work.
Downloading rust-lang/rust-analyzer…
(Requesting `rust-analyzer-x86_64-unknown-linux-gnu.gz'…)
############################################################################################################################################################## 100.0%
ziextract: Unpacking the files from: `rust-analyzer-x86_64-unknown-linux-gnu.gz'…
ziextract: Successfully extracted and assigned +x chmod to the file: `rust-analyzer-x86_64-unknown-linux-gnu'.
za-bgn-atclone-handler:227: no such file or directory: /home/mustaqim/.local/share/zinit/polaris/bin/rust-analyzer
chmod: cannot access '/home/mustaqim/.local/share/zinit/polaris/bin/rust-analyzer': No such file or directory
bin-gem-node annex: Something went wrong creating the rust-analyzer shim
With which module does that work? I have zdharma-continuum/zinit-annex-bin-gem-node
enabled.
Also I use the binary from inside Emacs, I don't use it from the terminal, so I don't need it as a shim as I link it to $HOME/.cargo/bin
.
This isn't directly related to the issue but I have to always set bpick
, otherwise is tries things like i686-unknown-linux-musl.tar.gz
What is the output of
echo $OSTYPE $MACHTYPE $CPUTYPE $(uname -a)
Have you tried removing the bpick lately? It's changed recently
linux-gnu x86_64 x86_64 Linux void 5.16.20_1 #1 SMP PREEMPT Thu Apr 14 17:43:53 UTC 2022 x86_64 GNU/Linux
I tried removing it but it chooses the wrong systems packages, either musl
or i686
or .vsix
in this case:
Downloading rust-lang/rust-analyzer…
(Requesting `rust-analyzer-linux-x64.vsix'…)
...
What's wrong with musl..? It's a selling point of Void
The musl libc, which focuses on standards compliance and correctness, has first-class support. This allows us to build certain components for musl systems statically, which would not be practical on glibc systems.
If you're not familiar with Musl, I suggest reading the Wiki page.
There's nothing at all wrong with it, though I did have problems with it and Android Studio. And also I am currently on a glibc system
whats the exact system youre using? from this post it looks like void linux, no?
Tangential, but you can run glibc programs on musl void and vice versa by utilizing private mount namespaces.
I might have been obtuse about my point. You should let zinit deduce the binary to pick via your system details. But if it works, it works.
Ya, with Void you can choose either to install musl or glibc (I'm on glibc), but in particular the musl rust-analyzer binary won't work because of its linked libs:
$ ldd ./rust-analyzer-x86_64-unknown-linux-musl
linux-vdso.so.1 (0x00007fff3dfb5000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f9a0fbbf000)
libc.musl-x86_64.so.1 => not found
libc.so.6 => /usr/lib/libc.so.6 (0x00007f9a0f9f9000)
/lib/ld-musl-x86_64.so.1 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f9a11464000)
And glibc:
$ ldd rust-analyzer-x86_64-unknown-linux-glibc
linux-vdso.so.1 (0x00007ffc9abda000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fe5e2863000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fe5e2849000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fe5e283e000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe5e281d000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fe5e26d8000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fe5e2512000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe5e42d5000)
That's why I need to have bpick
set, because for some reason on some occasions it attempts to download the musl binary
I think maybe this is because zinit isn't able to keep track of Nightly versions, that's why it doesn't update to the latest Nightly?
Ah okay, thanks for the elaborating on the bpick issue. Its really helpful. It should be fixed in #235.
As for the version issue, have you tried the 'ver' ice?
Its documented and there is an example in the wiki.
https://github.com/zdharma-continuum/zinit/wiki/🧊-Recommended-ices#neovim
Okay, thank you.
This is how I'm using it:
zi from"gh-r" nocompile ver"nightly" bpick"*linux-gnu.gz" mv"rust-analyzer-* -> rust-analyzer" fbin"rust-analyzer" for \
"rust-lang/rust-analyzer"
Now I'm wondering if something's wrong on my end, I copied the nvim example but it doesn't work:
zi for \
from'gh-r' \
sbin'**/nvim -> nvim' \
ver'nightly' \
neovim/neovim
Downloading neovim/neovim…
(Requesting `nvim-linux64.tar.gz'…)
############################################################################################################################################################## 100.0%
ziextract: Unpacking the files from: `nvim-linux64.tar.gz'…
ziextract: Successfully extracted and marked executable the appropriate files (nvim, python3complete.vim, pythoncomplete.vim, if_pyth.txt, remote_plugin.txt, less.sh) contained in `nvim-linux64.tar.gz'.
No files for compilation found.
Warning: ∞zinit-compile-plugin-hook hook returned with 1
za-bgn-atclone-handler:227: no such file or directory: /home/mustaqim/.local/share/zinit/polaris/bin/nvim
chmod: cannot access '/home/mustaqim/.local/share/zinit/polaris/bin/nvim': No such file or directory
bin-gem-node annex: Something went wrong creating the nvim shim
The polaris directory just has empty man folders, no bin directory or anything else
Works on my machine ;)
See if the sbin glob aligns with where the nvim binary is.
Any particular reason you're using fbin
?
but.. but... that's a .deb
!! Fine, here is the .tar.gz
;)
😁 Looks like I had to manually create the bin
folder in polaris
for sbin
to work. I was using fbin for a long time but it looks like things have changed since; I've switched to using sbin now
huh, you shouldn't have needed to create it manually. I dunno why, but feel free to open a new bug issue if it persists.
@mustaqimM Could you test out the branch of PR #235 ?
The tests look like it fixes the issue resulting in you need to use bpick.
https://github.com/zdharma-continuum/zinit/runs/6316146273?check_suite_focus=true#step:8:3319
Merged to main
Thank you so much @vladdoster, it seems like it's resolved now
Describe the bug
Hello, I have something like this (which I think there's redundant keywords in it):
The problem is if there's a Nighly update, the Release version is updated once to the Nightly version and now it hasn't updated to a newer Nightly version. How can I make sure it either updates to a newer Nightly, or only updates to stable Releases?
Steps to reproduce
.zshrc
Expected behavior
Update to latest Nightly, or stay on Stable
Screenshots and recordings
No response
OS / Linux distribution
Linux void 5.16.20_1 #1 SMP PREEMPT Thu Apr 14 17:43:53 UTC 2022 x86_64 GNU/Linux
Zsh version
5.8.1
Terminal emulator
foot
If using WSL on Windows, which version of WSL
No response
Additional context
No response