Cargo.lock must be updated too for version
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
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?
The Cargo.lock is not being changed at all.
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?
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
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
cargopresent? - Can we do it using warning if
cargois 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.lockname unlikely to be changed)
Let me know if this workaround is legit maybe I can have a chance to work on it.
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
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
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).