Cargo.lock is modified after running cargo package

[bk2204]

Problem
When using a Cargo.lock generated by 1.24.1, running cargo package modifies Cargo.lock and then fails without packaging anything. It's unexpected for cargo to modify any version-controlled file, and then to fail when the file has not been modified by the user. If the file is well-formed and semantically meaningful, it should be accepted without change by cargo package. If it is not, cargo should abort without modifying the file.

My projects have a strict version compatibility requirement so Cargo.lock is built with an appropriate version of the Rust toolchain. Because there's no way to explicitly pin packages to minimum versions or to force versions of packages that work with a specific Rust version, the building of Cargo.lock has to be done with an older version of the toolchain and hand-editing, so using a newer version of cargo to generate the file isn't a possibility here.

Steps

1. git clone https://github.com/bk2204/muter
2. cd muter
3. cargo package
4. git diff

Possible Solution(s)
Avoid adding the generated header unless the Cargo.lock is intentionally regenerated or is missing.

Notes

Output of cargo version:
cargo 1.45.1 (f242df6 2020-07-22)

This is with Rust 1.45.2 stable as a toolchain.

[Eh2406]

Can you elaborate on how you ended up pind to a version from 2.5 years ago?

[bk2204]

Sure. I have for many years supported certain Linux distros and their toolchains for a defined period. This policy has been in place for longer than Rust has been around. 1.24.1 is the version in Debian stretch, and therefore I supported it until Debian buster had been released for a year. I now support 1.34.2 and will until Debian bullseye has been released for a year.

I realize that this is not Rust upstream's preferred support policy, but I value compatibility with major Linux distros, especially Debian.

[Eh2406]

We talked about this in the Cargo Team meeting. We believe that it will be accepted without change if you pass the --locked flag, and the --frozen flag will abort without modifying the file. I hope that successfully gets you unstuck.

More generally there are plans in the works (#8554 for example) to make the way we upgrade the lockfile more consistent. Unfortunately for you, they are likely to be more consistently updating to newer formats. I am sorry.

[bk2204]

I did discover --locked after searching the source code. It wasn't apparent to me from the description in the --help output that it would have that effect; I didn't interpret “Require Cargo.lock is up to date” as indicating it wouldn't be modified. Maybe changing the description to “don't modify Cargo.lock; fail if out of date” or something similar would indicate this better.

[epage]

With the existence of --locked, I'm taking it there isn't anything more to do for this and am closing it. If there is something I missed, let us know!