Skip to content

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

Open
@kornelski

Description

@kornelski

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-lockfileArea: Cargo.lock issuesC-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions