chore: git-include Cargo.lock

[JohnTitor]

No description provided.

[gemini-code-assist]

Code Review

This pull request removes Cargo.lock from the .gitignore file and commits the generated lock file to the repository. The reviewer advises against this change, explaining that library crates should generally ignore the lock file to ensure compatibility testing against the latest dependency versions in continuous integration, as recommended by the Cargo Book.

[gemini-code-assist]

Committing Cargo.lock is generally discouraged for library crates. According to the Cargo Book, libraries should not check in their lock file. This ensures that the library is tested against the latest compatible versions of its dependencies in CI, which better reflects the environment of downstream users who will resolve dependencies based on their own lock files. Since netlink-proto is a library, it is recommended to keep Cargo.lock in .gitignore.

Cargo.lock
target

[cathay4t]

Any reason doing this? I have the impression that public crate does not include lock file.

[JohnTitor]

@cathay4t It's an old custom, see https://blog.rust-lang.org/2023/08/29/committing-lockfiles/ and https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control

[cathay4t]

I know the reason of doing that for a project exposing binary.

If we include Cargo.lock for crate like this, it is possible for consumer to holds multiple different version of same crate.

In fedora rust build guideline, they suggest all rust tool depend on latest compatible crate instead of this pinned one.

Above two links does not explain why a crate-only rust project should ship Cargo.lock.

[cathay4t]

IMHO, maintaining this Cargo.lock is time consuming with zero benefit? So I hope you could provide example on why it cause problem when lacking Cargo.lock?

[cathay4t]

Any explanation beside emoji?

[JohnTitor]

I don't agree with you at all.

If we include Cargo.lock for crate like this, it is possible for consumer to holds multiple different version of same crate.

I'm not sure what you mean, users can still choose via --locked or not.

In fedora rust build guideline, they suggest all rust tool depend on latest compatible crate instead of this pinned one.

It's totally unrelated to this topic.

maintaining this Cargo.lock is time consuming with zero benefit?

Explain why it's zero-benefit. Otherwise read the docs once again. You can ensure deterministic builds.

[cathay4t]

The https://github.com/rust-lang/log/blob/master/.gitignore indicate even rust-lang/log crate does not ship so.

And https://github.com/tokio-rs/tokio/blob/master/.gitignore neither.

I am aware of deterministic build, just don't know why it impact this rust-netlink fundamental crate.

I am no-issue-no-change dev. So I need proof on why make this change.

[cathay4t]

For MSRV stuff mentioned by FAQ doc. We have CI ensure we are good without this lock file.

[cathay4t]

If you claim it as old custom, please provide example library only crate who is shipping this lock file.

If you want this repo ship it, please explains which use case we are solving. And also explain how this file should be updated in the future release and CI tests.

Both rust-lang.org doc has zero explicitly suggestion on whether library only crate should ship it or not.