Update precise in offline mode

[dtolnay]

The following behavior was surprising to me:

$ cargo update
    Updating crates.io index
      Adding serde v1.0.124

$ cargo update -p serde --precise 1.0.123
    Updating crates.io index
    Updating serde v1.0.124 -> v1.0.123

$ cargo update -p serde --precise 1.0.124
    Updating crates.io index
    Updating serde v1.0.123 -> v1.0.124

$ cargo update -p serde --precise 1.0.123 --offline
error: you can't update in the offline mode

It seems to me that Cargo should already have all the information locally to perform the last update to 1.0.123 entirely offline. Why is network access required for that update?

As a workaround, editing an "=1.0.123" dependency into the Cargo.toml and using offline build commands (cargo check --offline) appears to perform that same update offline successfully.

---

Cargo version: most recent nightly -- cargo 1.52.0-nightly (c68432f 2021-03-02)

[Revantus]

I'd like to help with this.

Initial thoughts are that it should work for anything that has been cached previously. The --offline flag prevents the index and git from attempting to update so any missing cached dependencies will cause an error requesting to run without the --offline flag.

[alexcrichton]

I'd agree that this is a bug and I believe your thinking is correct @Revantus. Most likely there's some path in Cargo that's too eagerly returning an error when it shouldn't be, and the fix is probably just to remove the eager error or move it around.

[ehuss]

One could try removing the error here and see what breaks. I can't offhand think why it would cause any problems. There is a note in #4686 that cargo update should always fail due to "weird resolution errors", but I don't know what that means.

[Revantus]

@ehuss I replaced it there in my branch with logic to allow it when precise is specified. I also wrote up a test for it as well that passes. The update_lockfile function seems to take a different path than the compile commands. It looks like the resolver doesn't take any of the config settings into account when creating the update resolutions.

During testing I found that update does not respect source replacement during the initial resolutions. If a source pointing at crates.io is replaced with something else and that version doesn't exist/ isn't cached, the new source will point at crates.io internally and not get that replacement. This leads it to search for candidates in crates.io during the error resolution, since the filesystem registry wasn't taken into account. The --offline flag prevents it from actually updating that index still but I don't know if it can check against possibly different candidates already loaded. I assume this is why the "weird resolution errors" message exists. I'm setting up some local tests that use crates.io and combos of source replacement and patches to see if I encounter anything weird.

[ehuss]

Sorry, I'm a bit confused by the discussion of source replacement. cargo update isn't really intended to be used with source replacement active. I'm not sure how that relates to using it with --offline. That doesn't seem to be what this issue is about?

[Revantus]

It mostly just comes down to the resolution errors clarity for finding candidates in the case of missing dependencies. Build commands will still respect the source replacement so I don't see a security concern but I can see it causing extra confusion if the original source does have that dependency/version and lists it as a candidate.