support cargo-binstall

[2bndy5]

Is your feature request related to a problem? Please describe. I'm having trouble installing nur in WSL

$ cargo install nur
...
Caused by:
  failed to select a version for the requirement `zip = "~2.5.0"`
    version 2.5.0 is yanked
  location searched: crates.io index
  required by package `calamine v0.27.0`
      ... which satisfies dependency `calamine = "^0.27"` of package `nu-command v0.104.0`
      ... which satisfies dependency `nu-command = "^0.104.0"` of package `nur v0.16.0+0.104.0

Describe the solution you'd like Using cargo-binstall is an ideal alternative to platform-specific package managers and forcing users to build from source. It uses metadata from crates.io to download pre-built binaries from GitHub releases and places them into the same path that cargo install uses.

Combine cargo-binstall with cargo-update, and we've got cargo working as a practical cross-platform package manager for published binary crates.

[!tip] Using cross with vendored openSSL will make life easier in CI maintenance.

Describe alternatives you've considered The x86_64 tarball in the releases is not helpful either. When decompressing that and running ./nur in WSL, I got linker errors:

/path/to/nur-0.16.0+0.104.0-x86_64-unknown-linux-gnu/./nur: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /path/to/nur-0.16.0+0.104.0-x86_64-unknown-linux-gnu/./nur)
/path/to/nur-0.16.0+0.104.0-x86_64-unknown-linux-gnu/./nur: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /path/to/nur-0.16.0+0.104.0-x86_64-unknown-linux-gnu/./nur)
/path/to/nur-0.16.0+0.104.0-x86_64-unknown-linux-gnu/./nur: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by /path/to/nur-0.16.0+0.104.0-x86_64-unknown-linux-gnu/./nur)

Some extra details

> file /usr/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/x86_64-linux-gnu/libc.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=cd410b710f0f094c6832edd95931006d883af48e, for GNU/Linux 3.2.0, stripped
> sys host 
╭─────────────────┬────────────────────────────────────╮
│ name            │ Ubuntu                             │
│ os_version      │ 22.04                              │
│ long_os_version │ Linux (Ubuntu 22.04)               │
│ kernel_version  │ 5.15.167.4-microsoft-standard-WSL2 │
│ hostname        │ BDesktop2                          │
│ uptime          │ 2hr 22min 28sec                    │
│ boot_time       │ 2 hours ago                        │
╰─────────────────┴────────────────────────────────────╯
> rustc --version
rustc 1.87.0 (17067e9ac 2025-05-09)

Additional context Related to #7, but that solution offered installers uploaded to GitHub releases, instead of actual standalone binaries.

[2bndy5]

The fix for calamine dependence on zip is pending review: https://github.com/tafia/calamine/pull/506 I don't see any progress towards a workaround in nu-command deps.

[2bndy5]

Oh, it looks like cargo install nur --locked allows using the yanked version.

[ddanier]

Oh, it looks like cargo install nur --locked allows using the yanked version.

I think this is the current way it should always work. Thanks for the hint!

Regarding cargo-binstall: Can you point me to some docs to get this done? Alternatively would you be able to contribute the changes as a PR?

[2bndy5]

Regarding cargo-binstall: Can you point me to some docs to get this done?

See section in their README. If you think you'll need to customize the metadata cargo-binstall uses (in cargo.toml), they also have a supplemental SUPPORT doc for that as well.

Alternatively would you be able to contribute the changes as a PR?

I already attempted this on my fork, but I stopped when I hit the "Error type is too large" error. It looks like you resolved that in #54, so I'll rebase and take another look... IMHO, using a nu script (in CI) for releases adds complexity that I'm not accustomed to.

[!tip] You can inspect the what cargo-binstall does with:

cargo binstall nur --dry-run -v

The resulting Debug logs (due to -v) show what release assets it looks for.

[2bndy5]

I think the only thing stopping cargo-binstall from using the current release assets is the fact that the version published to crates.io (ie 0.17.0+0.105.1) is not the same as the tag pushed to GitHub (v0.17.0).

For example, the following works to install v0.17.0 from the Windows x86_64 zip asset (not msix installer):

cargo binstall nur --pkg-url="{ repo }/releases/download/v0.17.0/{ name }-{ version }-{ target }.{ archive-format }"

where the diff from default --pkg-url value is

-"{ repo }/releases/download/{ version }/{ name }-{ version }-{ target }.{ archive-format }"
+"{ repo }/releases/download/v0.17.0/{ name }-{ version }-{ target }.{ archive-format }"

[2bndy5]

I tried using the modified --pkg-url when installing to my RPi 64-bit (with all latest updates from apt), and cargo-binstall does install the aarch64-linux-unknown-gnu.tar.gz asset from the v0.17.0 release. But when I run nur, I get that linker error again:

/path/to/.cargo/bin/nur: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by /path/to/.cargo/bin/nur)

So, I think we'll need to cross-compile nur for Linux platforms using cross in CI. Hopefully, that will resolve the glibc version error.

I see there's a feature for non-Windows builds that enables vendering openssl: https://github.com/nur-taskrunner/nur/blob/090c27d98551f9cca2d2049a4070c368768e7e8a/Cargo.toml#L32-L37 That feature should make using cross easier since openssl is not typically available in the docker containers that cross uses (see their doc about this).

[2bndy5]

Ok, I'm working from Windows and I used WSL to run

cross build --target aarch64-unknown-linux-gnu --release --features static-link-openssl

Then, I copied the built binary to my RPi 64-bit, and it ran without any problems.

I think I have enough detail to put a PR together now. I'm going to double check the same approach works for the x86_64-linux-unknown-gnu target. And then I'll submit a PR.

About MacOS builds

I don't own any Apple devices to test with. I'm going to leave the current builds for MacOS as is unless directed otherwise.

[2bndy5]

Well, it turns out that if you wait long enough after releasing nur, cargo-quickinstall will build their own standalone binaries and cargo-binstall will pull pre-built binaries from the appropriate cargo-quickinstall releases once available.

For example, you can find the pre-built binaries for nur being deployed from cargo-quickinstall by searching their releases. As you'll see, their builds for nur are not exhaustive (missing some versions of nur).

---

@ddanier I'm still committed to rebasing my fork's branch for #57 until code review is completed (whatever direction you decide to take). #57 still fixes the GLIBC version error currently present in the releases' assets targeting Linux. I still think its better to serve official standalone binaries (built by this repo's CI) instead of relying on cargo-quickinstall.

[2bndy5]

BTW, this issue is preventing me from using/installing nur in CI because

1. It takes a significant amount of time to build from source.
2. Parametrizing the download URL (pointed at GitHub release assets) is too cumbersome when using nur in multiple workflows.

[2bndy5]

this issue is preventing me from using/installing nur in CI

I found a workaround for my CI workflows using exports from nurfile. Here's a brief example:

# in nurfile

# Runs clippy and rustfmt
export def --wrapped "nur lint" [
    ...args: string, # extra args passed to `cargo fmt`
] {
    cargo clippy
    cargo fmt ...$args
}

# in .github/workflows/rust.yml

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup nushell
        uses: hustcer/setup-nu@v3
        with:
          version: ${{ vars.NU_SHELL_VERSION || '*' }}
      - run: nu -c "use nurfile *; nur lint --check"

[ddanier]

First of all: Huge thanks to you for diving in so deep into this thing!

I'm willing to merge everything now, just did update some minor parts to ensure my workflows still work. I will still need to update https://github.com/nur-taskrunner/homebrew/blob/main/nurfile as well, but this is a separate repository.

Just to be clear about everything: When this is merged we a) have a cleaner pipeline, b) the Linux builds actually work and c) cargo bininstall does as well?

If you don't have any more open tasks I would say let's merge this. I will then create a patch release to check everything.

this issue is preventing me from using/installing nur in CI

I found a workaround for my CI workflows using exports from nurfile. Here's a brief example ...

Just a quick note about this: Yes it works, as nur basically does something similar. Still it does for example load the .env file and does load env and config nu scripts from the project. So it might behave differently. For many use cases still what you did here should just work. Thats the nice thing of nur being just this thin wrapper ;-)

[2bndy5]

I have no more ideas on this. I'll let you do your thing.

When this is merged we a) have a cleaner pipeline, b) the Linux builds actually work and c) cargo bininstall does as well?

a) yes b) yes c) yes as long as the tags match the crate version. cargo-binstall is smart enough to treat the prefixed v (ie v0.18.3+106.1) as optional. So, tags without the prefixed v will still work with cargo-binstall.

I will still need to update https://github.com/nur-taskrunner/homebrew/blob/main/nurfile as well, but this is a separate repository.

This reminds me: I've been wanting to pitch a similar idea about uploading releases to winget-pkgs. You already build a .msi installer... I'll just open a new issue to discuss. The user experience with homebrew would be similar for windows users where winget is available[^1].

[^1]: winget is not available for enterprise editions of Windows because it is tightly integrated with the Windows App Store. Although, you don't need to publish to the App Store if you want to publish to winget-pkgs.

Honestly, this project is so great! Making it easy to install/update would go a long way toward proliferation.