Will ".lock" file be updated after "cargo update"?

Hello,
In on the page 21 of the book of The Rust Programming Language, there is an example about the .lock file. I am a little confued about it.

For example, the first time when I add rand="0.8.5" beneath the [dependencies], as the newest the version of rand is 0.8.5, so the version of the rand will be locked to 0.8.5 in the .lock file.

A month later, the version of the newest rand is 0.8.9, but when I ran cargo build again, as the function of .lock file, so it still uses the rand with version of 0.8.5 not 0.8.9. I can understand this. But there are two questions about cargo update.

  1. If I ran cargo update a month later, will the version of rand be updated to 0.8.9? If it will, will the verson of the rand in the .lock file be changed to 0.8.9? If it will too, so I can't update the cargo, as it will change the lock file, which may cause problem for my programme. Am I right?
  2. If all the programme files were copied to a new laptop, in which the version of the cargo is different with the old one, such as on new laptop, it has run cargo update, run cargo build on this new laptop, and will it cause the .lock file changed? If it will, how can I guarantee my files can compiled correct on new computer same as on the old one?

Best regards,

The version in Cargo.lock will be updated, but the version in Cargo.toml will not (if you were worried about that). Rebuilding the project after that will then use the new version listed in the updated Cargo.lock.

By default, cargo update never updates past a SemVer break. For example, as long as your Cargo.toml says rand = "0.8.5", the Cargo.lock will only contain versions of rand in the 0.8.* range, never 0.9.0 or higher (unless something else in your dependency tree uses a newer version of rand, but that wouldn't affect the part of your code that uses rand). SemVer compatibility is taken very seriously by Rust programmers, and you can expect that an update within the 0.8.* range won't break your program (and, if it does, you have the right to file a bug report with the rand project).

Yes, because you ran cargo update.

You could simply not run cargo update.

3 Likes

You could simply not run cargo update .

But on another computer, such as my friends' computer, they may run, which may will casue something different. So, there is no way to restrict the version on all computers?

SemVer compatibility is taken very seriously by Rust programmers, and you can expect that an update within the 0.8.* range won't break your program (and, if it does, you have the right to file a bug report with the rand project).

In the book, it asssums that the version 0.8.6 will break the code.

Your friend could also break the code if they edit Cargo.toml or edit the source code. If other people are changing the project, nothing can guarantee the code will work and be the same afterwards.

If the text of the book matches what's currently displayed online, the actual quote is:

For example, say that next week version 0.8.6 of the rand crate comes out, and that version contains an important bug fix, but it also contains a regression that will break your code.

If version 0.8.6 contains a regression, that is a bug and a SemVer violation, and you have the right to file a bug report.

2 Likes

It's worth noting - if there is a bug in 0.8.6, and you want cargo update to never update to that, the syntax in Cargo.toml for that is:

[dependencies]
rand = "=0.8.5"

See: Specifying Dependencies - The Cargo Book

This is generally considered an antipattern, and rarely used. But it's worth knowing about in the offchance you do encounter a semver-breaking bug. I would suggest updating to 0.8.6 asap anyways, but if you can't for other reasons, this will let you represent that fact in Cargo.toml rather than relying on Cargo.lock never changing.

2 Likes

Perhaps you want to put Cargo.lock under version control, so that if you/others do run cargo update, then git status (or whatever) will make it clear that something has been changed, and git diff will show exactly what.

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.