commitizen icon indicating copy to clipboard operation
commitizen copied to clipboard

Cargo.lock must be updated too for version

Open lfdominguez opened this issue 1 year ago • 4 comments

Description

In rust when you change the version of the app, the Cargo.lock file must be changed too.

Possible Solution

Using the same toml parser, must change the package->name = <same that Cargo.toml>->version

Additional context

No response

Additional context

No response

lfdominguez avatar Aug 08 '24 00:08 lfdominguez

Is the issue that the Cargo.lock file is not being changed at all or is the issue that Cargo.lock is not being added to the commit?

marcusalstrom avatar Oct 06 '24 15:10 marcusalstrom

The Cargo.lock is not being changed at all.

woile avatar Oct 06 '24 15:10 woile

I attempted to reproduce this in my Rust project. After creating a commit with cz commit, I executed cz bump to update the version, and both the Cargo.toml and Cargo.lock files correctly reflected the version change. How exactly can I reproduce this bug?

marcusalstrom avatar Oct 06 '24 15:10 marcusalstrom

Normally if your editor is running, it will pick up changes to the folder, and run cargo commands which automatically update the .lock. That's why if you update the Cargo.toml manually, you will see it in the .lock.

Fixing this is actually a bit hard because of workspaces, and because you can define workspaces with globs, and exclude like:

[workspace]
members = ["crates/*"]
exclude = ["crates/foo"]

so you'd have to use glob.glob from python to include, and then exclude those matching the exclude, and afterwards filter from all the found crates those with version = { workspace = true }, and finally, the resulting crates should be updated on the .lock

woile avatar Oct 06 '24 16:10 woile

Hi @woile and @Lee-W I have an idea, what if we use something like

        if provider.config.settings.get("version_provider") == "cargo":
            cmd.run("cargo generate-lockfile")
            files.append("Cargo.lock")   # bump's commit files

in commitizen/commands/bump.py we could solve this problem, by cargo's native way

But things need to clarify are:

  • How to ensure that user's project have cargo present?
  • Can we do it using warning if cargo is not present

References:

  • https://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.htmlhttps://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.html
  • https://github.com/rust-lang/cargo/issues/8498 (Cargo.lock name unlikely to be changed)

Let me know if this workaround is legit maybe I can have a chance to work on it.

changchaishi avatar Dec 24 '24 05:12 changchaishi

This workaround looks good to me, and we probably need to make this behavior configurable and default to false.

How to ensure that user's project have cargo present?

run it without encountering error code or using which

Can we do it using warning if cargo is not present

a warning should be good enough I think

Lee-W avatar Dec 25 '24 00:12 Lee-W

I would avoid the dependency with cargo. It won't really work with the GitHub actions and dockerfile's. So it will only create problema for people who run it in their computers and it works and then it won't work in the CI. I'm working on a PR to fix the lock file automatically, luckily it's only toml

woile avatar Dec 25 '24 07:12 woile

I think that the best approach it's only to modify the cargo.lock with toml lib, not using cargo to recreate the cargo.lock (i think that a change on the version field must not touch anything else on the cargo.lock file).

lfdominguez avatar Dec 25 '24 17:12 lfdominguez