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 must be updated too for version #1201

Open
lfdominguez opened this issue Aug 8, 2024 · 8 comments
Open

Cargo.lock must be updated too for version #1201

lfdominguez opened this issue Aug 8, 2024 · 8 comments

Comments

@lfdominguez
Copy link

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

@marcusalstrom
Copy link

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?

@woile
Copy link
Member

woile commented Oct 6, 2024

The Cargo.lock is not being changed at all.

@marcusalstrom
Copy link

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?

@woile
Copy link
Member

woile commented Oct 6, 2024

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

@changchaishi
Copy link

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:

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

@Lee-W
Copy link
Member

Lee-W commented Dec 25, 2024

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

@woile
Copy link
Member

woile commented Dec 25, 2024

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

@lfdominguez
Copy link
Author

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants