[bug]: Choosing version track such as Nightly as the version to stay on

mustaqimM commented 2 years ago

Describe the bug

Hello, I have something like this (which I think there's redundant keywords in it):

zi ice lucid cloneonly from"gh-r" bpick"*linux-gnu.gz" mv"rust-analyzer-* -> rust-analyzer" fbin"rust-analyzer"
zi light "rust-lang/rust-analyzer"

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

Add above snippet to .zshrc
Reload terminal to install

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

vladdoster commented 2 years ago

Have you had a chance to look at the documentation? This is almost certainly not a bug.

vladdoster commented 2 years ago

Also, what command(s) are you using to update plugins?

vladdoster commented 2 years ago

Does that recipe work? I've modified it for macOS, but it doesn't seem to work?

vladdoster commented 2 years ago

it can be rewritten:

zi from'gh-r' nocompile sbin'*->rust-analyzer' for \
  rust-lang/rust-analyzer

mustaqimM commented 2 years ago

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.

mustaqimM commented 2 years ago

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

vladdoster commented 2 years ago

What is the output of

echo $OSTYPE $MACHTYPE $CPUTYPE $(uname -a)

vladdoster commented 2 years ago

Have you tried removing the bpick lately? It's changed recently

mustaqimM commented 2 years ago

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'…)
...

vladdoster commented 2 years ago

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.

mustaqimM commented 2 years ago

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

vladdoster commented 2 years ago

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.

vladdoster commented 2 years ago

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.

mustaqimM commented 2 years ago

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?

vladdoster commented 2 years ago

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?

vladdoster commented 2 years ago

Its documented and there is an example in the wiki.

https://github.com/zdharma-continuum/zinit/wiki/🧊-Recommended-ices#neovim

mustaqimM commented 2 years ago

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

vladdoster commented 2 years ago

Works on my machine ;)

vladdoster commented 2 years ago

See if the sbin glob aligns with where the nvim binary is.

vladdoster commented 2 years ago

Any particular reason you're using fbin?

vladdoster commented 2 years ago

but.. but... that's a .deb!! Fine, here is the .tar.gz ;)

mustaqimM commented 2 years ago

😁 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

vladdoster commented 2 years ago

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.

vladdoster commented 2 years ago

@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

vladdoster commented 2 years ago

Merged to main

mustaqimM commented 2 years ago

Thank you so much @vladdoster, it seems like it's resolved now

zdharma-continuum / zinit