Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo.lock contains project's own version, unnecessarily #5979

Open
kornelski opened this issue Sep 5, 2018 · 0 comments
Open

Cargo.lock contains project's own version, unnecessarily #5979

kornelski opened this issue Sep 5, 2018 · 0 comments
Labels
A-lockfile Area: Cargo.lock issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-team-input Status: Needs input from team on whether/how to proceed.

Comments

@kornelski
Copy link
Contributor

kornelski commented Sep 5, 2018

In Cargo.lock there's a [[package]] entry for the project itself (workspace members, technically), and like all entries, it contains a version field.

If I bump the version in Cargo.toml, the Cargo.lock version becomes out of sync, and that causes some annoyances for a project that keeps Cargo.lock under version control:

  • When I bump the project version, I have to remember to also run some lock-rewriting Cargo command to update the lockfile version, even if I don't intend to update any dependencies. This feels like an unnecessary step to be mindful of.

  • OTOH, if I don't update the lockfile at the same time when bumping the version, some future operation will. This causes an unwanted/unrelated change in a later commit in the project.

Fortunately, it looks like the version in Cargo.toml is not actually used for anything important. Ideally, I'd like to completely remove the version field from packages in Cargo.lock that are workspace members, but for better backwards compatibility, the version could be locked to some constant value (e.g. 0.0.0-workspace).

Technically it seems possible: in EncodableResolve::into_resolve(), when EncodableDependency is in the workspace, use the version from the ws.members() instead.

Does that make sense? Would that work? Would you accept such change?

@alexcrichton alexcrichton added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Sep 5, 2018
@ehuss ehuss added the A-lockfile Area: Cargo.lock issues label Apr 6, 2020
@weihanglo weihanglo added the S-needs-team-input Status: Needs input from team on whether/how to proceed. label Oct 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lockfile Area: Cargo.lock issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-team-input Status: Needs input from team on whether/how to proceed.
Projects
None yet
Development

No branches or pull requests

4 participants