Cargo update -p <localcrate> in a workspace has inconsistent behaviors

[roblabla]

Cargo's handling of cargo update -p <cratename> is extremely inconsistent. Depending on how local crates are named or how up-to-date the Cargo.toml is compared to the Cargo.lock file, it will behave very differently with regards to git dependencies.

I have created a repository explaining the problems I found @ https://github.com/roblabla/cargo-wtf-why-are-you-drunk/

In that repository, you'll find two examples of inconsistencies in the behavior of cargo update -p:

• In the first one, we show that cargo seems to handle git dependencies differently depending on whether it's got "work" to do on local crates or not. In particular, in my local monorepo, if I bump the version of a local crate in Cargo.toml, then cargo update -p <crate> will update the local lockfile to bump the versions of crate and nothing else. However, if I don't bump the version and run the same cargo update -p <crate> command, cargo will update the git dependencies.

  This discrepancy is especially frustrating, as it complicates our release process by making bumping the version more complicated.

• In the second one, we show that whether or not cargo updates the git dependencies after bumping the version seem to depend on how your local crates in your workspace are named. This makes any call to cargo update -p <crate> inherently fragile, as what it does will depend on how your dependencies are named.

Possible Solutions

IMO, cargo update -p <crate> should never update an unrelated git dependency, as it does not match what the user intended.

Rust version:

rust 1.71.0 (8ede3aae2 2023-07-12)

[epage]

So exhibit 2 involves running cargo update -p <workspace-member> and a git dependency gets updated.

I ran CARGO_LOG=trace and did a diff of the logs.

The sad case has a long list of

ignoring any lock pointing directly

that when only 1 exists in the happy case.

[epage]

It looks like our tracking of what should be ignored is order dependent, depending on whether the package with the changed version is seen first or not.

[epage]

@roblabla your Exhibit One reproduction cases have trigger.sh with different behavior. Could you unify them in the direction that is needed?

[epage]

Correction, I'm assuming that difference is intended to showcase the difference in behavior.

We have a check where we only avoid a path dependency if its changed. That "if" i what is causing the problem here.

[roblabla]

Correction, I'm assuming that difference is intended to showcase the difference in behavior.

Yeah, the trigger.sh in the happy case changes the version in the manifest, while in the sad case it doesn't, which causes the unexpected difference in behavior.

[epage]

@Eh2406 for Exhibit One (cargo update -p workspace-member updating git deps when there is nothing to update for the workspace member),removing if pkg.package_id() != node seems to fix it but I'm hesitant to just randomly delete code. Thoughts?

[epage]

@roblabla seems like these problems are very different, even in reproduction steps (one being order dependent while the other one isn't). Please in the future create separate Issues so we can more easily track the individual conversations and progress.

[roblabla]

Alright. Reason they're together is that I actually discovered exhibit 2 while trying to reproduce exhibit 1 😅

[epage]

@roblabla as an update, my change in #12602 was incorrect and it is now changed so you'll be seeing git updates in more cases.

We still need to dig into if its possible to skip these git updates. They go through a bit of a different path to evaluate if we should update because we only allow one version in the dependency graph and we'll need to further evaluate what can and shouldn't be changed there.