Feature request: Make cargo-update aware of cargo-binstall

[auronandace]

Would it be possible to make cargo-update aware of packages that have been installed via cargo-binstall?

Link: https://github.com/ryankurte/cargo-binstall

As a bonus it would be great if it could detect whether some packages have the option to install via cargo-binstall and display that when you use the -l option for listing updates.

[nabijaczleweli]

Closing as fundamentally impossible: cargo-binstall doesn't actually install anything, it seems, just copies stuff around:

testpsko@tarta:~$ tree -a .cargo/
.cargo/
├── bin
│   ├── cargo
│   ├── cargo-binstall
│   ├── cargo-clippy
│   ├── cargo-fmt
│   ├── cargo-miri
│   ├── clippy-driver
│   ├── rls
│   ├── rustc
│   ├── rustdoc
│   ├── rustfmt
│   ├── rust-gdb
│   ├── rust-lldb
│   ├── rustup
│   ├── sx128x-util -> sx128x-util-v0.17.2
│   └── sx128x-util-v0.17.2
├── .crates2.json
├── .crates.toml
├── env
└── .package-cache
testpsko@tarta:~$ grep -r sx128x .cargo/
grep: .cargo/bin/sx128x-util-v0.17.2: binary file matches

It's equivalent to just putting random stuff in ~/.cargo/bin, so nothing actually knows about it, not even cargo-binstall.

[Jackenmen]

Since version 0.10.0, cargo-binstall mimics cargo install's installation process of using .crates.toml and .crates2.json so that it's actually more of an install rather than just putting binaries in ~/.cargo/bin.

Is there anything else that would be needed before it's realistically possible to implement such feature?

[nabijaczleweli]

Yes, that's possible now, and I have a PoC draft. However, cargo-binstall is currently not fit for purpose:

• https://github.com/ryankurte/cargo-binstall/issues/267
• https://github.com/ryankurte/cargo-binstall/issues/268
• https://github.com/ryankurte/cargo-binstall/issues/269
• https://github.com/ryankurte/cargo-binstall/issues/270 So.

[passcod]

Hi, maintainer from cargo-binstall here.

Thank you for your expert feedback, and bear with us as we take it under advisement and work to resolve issues. We do appreciate your help in making our tool more robust and understand not wanting to integrate before it feels ready.

We are not yet at 1.0.0 and are likely to have some minor breaking changes to the interface before then. If that sounds like too much trouble, do tell us and we can post here when we get to a stable place we feel comfortable calling 1.0 so an integration can further proceed. Obviously as fellow open source maintainers we'd like to avoid the annoyance of others where we can.

[nabijaczleweli]

@jack1142 can you try the current master branch (at least 558c3f5d10c9127e1febea53766e3df49019afca) against cargo-binstall >=0.12?

[Jackenmen]

Aside from me running into an entirely different issue while trying it (unrelated to this change, it happens on the released version of cargo-update as well, see #187), it appears to be working fine. Due to the mentioned issue, I wasn't able to check if it handles git install fine but I imagine it would.

[nabijaczleweli]

Git installation is entirely unaffected by this, which I assume is expected?

[Jackenmen]

Yes, that's expected, just wasn't sure whether you replace all usage of cargo with binstall when available or just for packages installed from the cargo index so I didn't know if that should be tested as well.

[nabijaczleweli]

Released in v8.2.0.