- If the file exists,
cargo will use
Cargo.lock to decide which dependencies to download and build.
cargo update is effectively equivalent to removing
Cargo.lock and then running
cargo build if there wasn't a
cargo clean in-between. It updates
Cargo.lock with more recent compatible versions of packages in the repo.
- Cargo uses feature unions if two crates have a dependency on the same version of another crate (including version) and they enable different features (Source1) (Source2).
- By convention, according to Discourse forums and cargo devs,
cargo features are supposed to be additive. This has been known to break
- This feature-union convention could be subject to change in the semi-near future? I wonder if the old behavior could also possibly be kept to facilitate dependency reuse/not having multiple versions of the same crate in a library/application...
- The same crate with two different versions are not considered the same crate, and trying to use types from one crate in another will error out.
- Caret versioning is default in
Cargo.toml. See here for more information about what a compatible version means. I.e. if not using
cargo will check if a newer version exists (both on disk and from the repo) before deciding what version of a crate to (possibly download and) build.
- With caret versioning, it is possible that two crates specifying two different versions of a crate dependency end up both using- and sharing!- a newer third version instead.
cargo works on a DAG, crates whose deps were updated as a result of
cargo update (which can happen if their
Cargo.tomls use caret versioning) will be rebuilt as well.
- If you have a wildcard dependency and a clean build,
cargo will use the most up-to-date version from the repository.
If you change a concrete version of a dependency to a wildcard, and do not clean your dependencies (and delete I can't seem to duplicate this. Looks like I forgot to delete
cargo will use the existing crate version on-disk already to satisfy the wildcard, even if its a less recent version.
Cargo.lock when I observed this behavior? See CargoDump.
cargo doesn't download/build crates if it doesn't have to. This can be demonstrated by taking a repo with dependencies still intact, making a copy of
cargo build, and then replacing the updated
Cargo.lock with the old one.
- Because a binary built with the old
Cargo.lock already exists,
cargo will simply hard link the binary under
target to the existing old binary to "build" it.