3 ms·

> Normal cargo + crates.io usage has the same property via the existence of lockfiles. For most people that care about stability, this will provide a natural de

> Normal cargo + crates.io usage has the same property via the existence of lockfiles. For most people that care about stability, this will provide a natural delay (which you can also see in crates.io download graphs) to consuming the latest version. Be aware however that lock files are ignored by default. You need to specify "--locked" if you want Cargo to use the "locked" versions from Cargo.lock. > By default, the Cargo.lock file that is included with the package will be ignored. This means that Cargo will recompute which versions of dependencies to use, possibly using newer versions that have been released since the package was published. https://doc.rust-lang.org/cargo/commands/cargo-install.html#dealing-with-the-lockfile https://doc.rust-lang.org/cargo/commands/cargo-install.html#...

hobofan 3y ago
This only applies to the `cargo install` command to install binaries from crates.io. If you work in a repository on your own project and use basically any other cargo command (e.g. `cargo build`, `cargo run`), the lock file is of course taken into account (otherwise it would be near-useless).
- frankjr 3y ago
  Right but that's not the only use case for `cargo install`. You can also use it to install binaries system wide from cloned repositories (`cargo install --path .`). I use this often for small utilities (for which I have no intention of publishing to crates.io) or when testing before packaging for Arch.
MrJohz 3y ago
This is installing binaries from crates.io directly (i.e. running "cargo install ripgrep" instead of "sudo apt..." or whatever equivalent). Admittedly, this is often a suggested installation method for some built-in-Rust tools, but it's usually an option of last resort, and most people should be using their usual package manager for this. Cargo does respect the package lock file when building a project from source (i.e. when you checkout a project, and run `cargo build` in that project directory). This happens, for example, when running builds in CI, or preparing a new release for each individual package manager.
- frankjr 3y ago
  I responded in a sibling comment because it came first.

hobofan 3y ago

This only applies to the `cargo install` command to install binaries from crates.io. If you work in a repository on your own project and use basically any other cargo command (e.g. `cargo build`, `cargo run`), the lock file is of course taken into account (otherwise it would be near-useless).

frankjr 3y ago
Right but that's not the only use case for `cargo install`. You can also use it to install binaries system wide from cloned repositories (`cargo install --path .`). I use this often for small utilities (for which I have no intention of publishing to crates.io) or when testing before packaging for Arch.

MrJohz 3y ago

This is installing binaries from crates.io directly (i.e. running "cargo install ripgrep" instead of "sudo apt..." or whatever equivalent). Admittedly, this is often a suggested installation method for some built-in-Rust tools, but it's usually an option of last resort, and most people should be using their usual package manager for this. Cargo does respect the package lock file when building a project from source (i.e. when you checkout a project, and run `cargo build` in that project directory). This happens, for example, when running builds in CI, or preparing a new release for each individual package manager.

frankjr 3y ago
I responded in a sibling comment because it came first.