What's the consequences of versioning Cargo.lock?

[paul-hansen]

Does anyone know how the Cargo.lock file that accesskit ships gets treated when used in a downstream library like Bevy? Is it ignored, or is it enforced?

If enforced, would that mean that we could end up with duplicate versions of crates even though they are version compatible?

If ignored, less of a problem but would probably mean that AccessKit's CI isn't always testing what the end users would be seeing.

The documentation here seems to suggest it's enforced https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries and to me that seems like it could be problematic as AccessKit could be preventing downstream binaries/libraries from getting the latest patch fixes for any crates AccessKit uses until AccessKit updates their lock file. Maybe AccessKit should consider making a nightly GitHub action to help keep it up to date? Hoping I'm wrong and it's fine somehow.

[kpreid]

The documentation here seems to suggest it's enforced

No, the opposite. This sentence is describing Cargo's behavior:

Users dependent on the library will not inspect the library’s Cargo.lock (even if it exists).

(There is one case where a published package's lockfile is consulted, and that is cargo install --locked.)

The recommendation to not check in lock files for libraries is due to the fact the lockfile won't be used by dependents, and therefore the library development process should not assume a particular lockfile state. Also, the recommendation is likely to be changed to the opposite.

[paul-hansen]

I'm seeing it now thanks!

I think I originally mistook the line you quoted to mean that it shouldn't be versioned because users wouldn't read it, as in users being people, who were physically inspecting it. Reading it again I think your interpretation is correct and now that section makes more sense.