GeezerVison is showing github.com — migrate rust language's addition-dependencies to use cargo install · Issue #3278 · pre-commit/pre-commit
migrate rust language's addition-dependencies to use cargo install #3278Descriptionsearch you tried in the issue tracker
rust
describe your actual problem
This is following the discussion about allowing cargo features to be used in rust-based hooks (started in #3230 continued in #3235).
The cargo add command has been used since 2018 to add dependencies to a rust-based hook's manifest (Cargo.toml). Sometime since then (probably when 2021 edition was stabalized), cargo features were implemented in the cargo install command. As noted in #3235 (comment), this makes cargo install more suitable for a rust-based hook's additional-dependencies because it actually installs additionally specified dependencies.
Tip Using --locked better assures expected install behavior. However, this is not the default for cargo install.
pre-commit --version
3.7.1 Activitymondeja commented on Oct 13, 2024 What about installing pre-built binaries with cargo binstall if available for cli: dependencies? That would make a lot of installations really faster. Reacted by Brendan, pravic and Benjamin Bannier 2bndy5 commented on Oct 13, 2024 Agreed, but compatibility with cargo-binstall cannot be assumed/guaranteed. cargo-binstall support is largely a voluntary effort on behalf of developers and may actually fall under pre-commit's system language. pravic commented on Dec 3, 2024
but compatibility with cargo-binstall cannot be assumed/guaranteed
And yet, pre-commit could detect cargo-binstall and use it instead of cargo install. Especially, given the fact that binstall falls back to installing from source if a binary distribution isn't available. Reacted by João M. Martins and Benjamin Bannier 2bndy5 commented on Sep 24, 2025
but compatibility with cargo-binstall cannot be assumed/guaranteed
And yet, pre-commit could detect cargo-binstall and use it instead of cargo install. Especially, given the fact that binstall falls back to installing from source if a binary distribution isn't available.
By "compatibility", I meant that the pre-commit hook's GitHub releases need to have assets that comply with cargo-binstall's strategy. Its probably not a big deal since cargo-binstall will fallback to cargo install if 1the release asset is not present or 2quick-install repo hasn't built the version of the requested crate.
FWIW, I use cargo-binstall wherever possible. Although, forcing it on end-users may not be an ideal approach. There's a provenance concern and privacy concern (about cargo-binstall's analytic data gathering) which should err toward building from sources hosted on crates.io by default. But, it would be nice if pre-commit hook authors could opt-in to using cargo-binstall. pravic commented on Sep 24, 2025
Although, forcing it on end-users may not be an ideal approach.
In case of using precommit locally, using cargo-binstall is literally an opt-in. Because in order to be used, it needs to be installed first on the host machine.
But I can't speak for GitHub actions - but at least they are parametrized, right? So, a GitHub action user could opt-in for cargo-binstall as well. asottile commented on Sep 24, 2025 install / binstall is off topic for this issue -- this issue is about removing cargo add
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|