Policy on `Cargo.lock`s would be good

[finalyards]

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   examples/esp32/Cargo.lock
	modified:   examples/nrf-sdc/Cargo.lock

That happened quite a bit, working on a PR today. Made me wonder, whether the lock files actually matter, for examples.

Current situation

/.gitignore states that all Cargo.locks should be ignored (not suggested to be placed to version control).

Cargo.lock

However, there clearly are instances already in the version control. Otherwise, I wouldn't have gotten the "modified" mentions, above.

./examples/apache-nimble/Cargo.lock
./examples/rp-pico-w/Cargo.lock
./examples/nrf-sdc/Cargo.lock
./examples/esp32/Cargo.lock
./examples/serial-hci/Cargo.lock

This is inconsistent, at best.

The esp-hal project has this approach to including Cargo.locks, within a repo:

# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
Cargo.lock

"Leave it for libraries".

All the ones we have are for examples. I think they can go? ((give a nudge and I'll make a PR that removes them, making the repo consistent with what's in its /.gitignore))

But shouldn't we actually have it for the libraries (host and host-macros)?

Should I add those in the same PR?

[HaoboGu]

https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html is quite clear, Cargo.lock in examples(bin) can be kept, and for libs like host and host-macros they should not be committed.

[lulf]

Yes, examples committed and libs not committed is the policy. We could move the .gitignore rules for ignoring lock files to the host and host-macros subdirectories.

[finalyards]

Thanks! I don't know why I got it exactly the other way round!

We could move the .gitignore rules for ignoring lock files to the host and host-macros subdirectories.

I can craft such a PR.

What about the inconsistency that some examples currently have it, some don't? That will likely cure itself over time, once the Cargo.lock is not categorically excluded. Or should I add the files for (currently without a lock):

./host/Cargo.lock
./bt-hci-linux/Cargo.lock
./examples/tests/Cargo.lock
./examples/rp-pico-2-w/Cargo.lock
./examples/linux/Cargo.lock
./examples/apps/Cargo.lock
./benchmarks/nrf-sdc/Cargo.lock
./host-macros/Cargo.lock

This would make the repo consistent.

[lulf]

You can add these:

./examples/rp-pico-2-w/Cargo.lock
./examples/linux/Cargo.lock
./benchmarks/nrf-sdc/Cargo.lock

The rest should be in the ignore file.

[finalyards]

Great.

One more question: when running CI-like scripts locally, I end up having many, version controlled Cargo.locks updated:

modified:   examples/esp32/Cargo.lock
modified:   examples/nrf-sdc/Cargo.lock
modified:   examples/rp-pico-w/Cargo.lock
modified:   examples/serial-hci/Cargo.lock

I will now just restore the changes made into the unrelated examples, but what is the right approach? How do you others deal with this?

[finalyards]

I feel like this is a can-of-worms.

Right now, I come from a race 🚗 between me and my IDE.

I wanted those changes gone, git restore. The IDE kept bringing them back...