cargo generate-lockfile shouldn't silently update an existing one

[sfackler]

It should probably act like cargo build does, where it generates a new lockfile if one doesn't exist, and and performs minimal updates to account for changes if one does.

[alexcrichton]

I think we basically just need to remove the generate_lockfile function and call resolve_ws instead.

[epage]

With backwardss compatibility on this, is there something worth doing?

My main workaround for this is cargo update --workspace.

[eric-seppanen]

I would love to see this happen; if backwards compatibility is an obstacle the second-best thing IMO would be to add a commandline flag to make it do resolve_ws instead of what it does currently.

I have encountered this limitation several times:

• Cross-workspace automation: based on what's happening in workspace A, I may want to inspect what, if any, lockfile changes would result in workspace B (that is importing a crate from workspace A).
• When showing people surprising behavior in dependency resolution (e.g. #5529), I find myself wishing for a tool to "resynchronize Cargo.lock" and nothing else..
• When resolving lockfile git conflicts, I would like to be able to script the "throw away the conflicted version and regenerate the lockfile" without getting unintentional dependency upgrades.

I also wonder if this is just the place that users are likely to look for this functionality: it may be a user-experience bug to give users a tool called "generate-lockfile" that can't do the lockfile generation step that every other cargo command does implicitly.

I am not familiar with cargo update --workspace though. Its help text "Only update the workspace packages" doesn't really mean anything to me?

[epage]

I would love to see this happen; if backwards compatibility is an obstacle the second-best thing IMO would be to add a commandline flag to make it do resolve_ws instead of what it does currently.

Independent of this specific situation, what I consider with flags are

• Can we communicate this clearly?
• How well can the user discover this? This includes "they ran the command naively and it did the wrong thing".
  • This is at least better than cargo publish behavior where generally there will be a committed version of the lockfile to recover to.
• How much value does this flag provide to outweigh the cost of more existing in the public interface which, at a certain point, each new part of the interface makes it harder to discover what else is there which reduces value for everyone.
  • At least cargo generate-lockfile is fairly specific and so doesn't have nor do I expect it to have many knobs.

Cross-workspace automation: based on what's happening in workspace A, I may want to inspect what, if any, lockfile changes would result in workspace B (that is importing a crate from workspace A).

Semantically, this feels weird to call cargo generate-lockfile for.

When resolving lockfile git conflicts, I would like to be able to script the "throw away the conflicted version and regenerate the lockfile" without getting unintentional dependency upgrades.

This would be a little different: if there is a parse error, throw out the entire lockfile. If we don't throw away the lockfile otherwise, I wonder if this would be surprising.

[eric-seppanen]

When resolving lockfile git conflicts, I would like to be able to script the "throw away the conflicted version and regenerate the lockfile" without getting unintentional dependency upgrades.

This would be a little different: if there is a parse error, throw out the entire lockfile. If we don't throw away the lockfile otherwise, I wonder if this would be surprising.

I didn't mean that I was exposing the conflicted Cargo.lock directly to cargo. I meant that I want a shell script that reverts Cargo.lock to the previous commit, and then runs a cargo command that regenerates only the necessary changes, without attempting to build/check anything.

If this were lightweight enough, I could even run git rebase --exec redo-cargo-lock and have it do the right thing.

[eric-seppanen]

Cross-workspace automation: based on what's happening in workspace A, I may want to inspect what, if any, lockfile changes would result in workspace B (that is importing a crate from workspace A).

Semantically, this feels weird to call cargo generate-lockfile for.

I do a lot of weird things :) I mentioned this one out of completeness, not because I think it's common enough to get first-class support. But it was the one I was working on today, and while trying to remember whether there was a way to do "lightweight lockfile resync" I rediscovered this issue.