Add some help with updating the registry in offline mode. #6871
Conversation
|
This is an attempt to improve some error message, but I'm on the fence if it actually does that, so I figured I'd post this for comments. I think I'm not sure if the The I'm not sure if the wording is clear. |
|
r? @nrc (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
ehuss
force-pushed
the
offline-spurious-suggestion
branch
from
42e95c2
to
f876910
Compare
src/cargo/sources/registry/remote.rs
Outdated
| if let Err(e) = result { | ||
| let extra = if maybe_spurious(&e) && nightly_features_allowed() && !repo.is_empty()? { | ||
| "\nIf the network is unavailable, consider running with the -Zoffline \ | ||
| flag to run in offline mode." |
There was a problem hiding this comment.
This warning I'm somewhat wary about because it feels a little aggressive about mentioning -Zoffline. We're already pretty fast-and-loose with what we interpret as spurious network error (we're rarely sure that it's a spurious error, it's just a random bucket of things that are all somewhat network related).
I'm personally wary of CI tools that make suggestions which often don't end up being applicable as well because it can be a frustrating experience. Ideally we'd recognize a spurious error, actually run resolution in offline mode, realize it works, and only then actually emit an appropriate error. That seems a bit heavy handed and a bit far fetched though.
Do you think though that if we don't have this sort of an error message then -Zoffline will be difficult to discover?
There was a problem hiding this comment.
Yea, this is only for discoverability. Should I just remove this, or would it be worthwhile to emit a warning and see if it can succeed to resolve? I lean towards just removing it.
There was a problem hiding this comment.
This also fires for cargo install which will give a bad suggestion, cargo install foo -Z offline will fail, so I think the risk of a bad suggestion is a little too high.
There was a problem hiding this comment.
Hm those are good points yeah. I'm fine with landing without this and we can sort of see over time whether we feel that we need to improve the error messages for offline.
| Run `cargo fetch` to download the registry index and all \ | ||
| of a project's dependencies before going offline.", | ||
| self.source_id | ||
| ); |
There was a problem hiding this comment.
Could you add a comment here that we're explicitly switching the Ok to an Err because if we're updating the index we're guaranteed to require at leats one crate and since the index is empty it's guaranteed to have zero crates, therefore we're trying to give a better error message
There was a problem hiding this comment.
Hm, this suggestion is also a little sketchy. If you run cargo install foo for the first time, and the index is unavailable, it suggests running cargo fetch which will definitely not work. Maybe it is not worth it?
There was a problem hiding this comment.
That's a good point yeah, but I think that could be fixed by tweaking the error message? It could mention that you should try running with out --offline or otherwise run cargo fetch sooner perhaps?
This makes two changes: - If an index has never been downloaded, and `-Z offline` is used, provide a suggestion to run without `-Z offline`. - If an index needs to be updated, and the network appears to be down, suggest running with `-Z offline`.
This is just too likely to be a false positive, or otherwise a bad suggestion.
ehuss
force-pushed
the
offline-spurious-suggestion
branch
from
f876910
to
c6fad3a
Compare
|
OK, I reverted the spurious error, and tweaked the text of the other one. |
|
@bors: r+ |
|
📌 Commit c6fad3a has been approved by |
bors
added
S-waiting-on-bors
Add some help with updating the registry in offline mode. This includes the following: - Move offline tests to a dedicated file. - If an index has never been downloaded, and `-Z offline` is used, provide a suggestion to run without `-Z offline`. - ~~If an index needs to be updated, and the network appears to be down, suggest running with `-Z offline`.~~ (removed this) - The `offline_resolve_optional_fail` test is added to show that resolver errors are still possible (though hopefully rare!).
|
☀️ Test successful - checks-travis, status-appveyor |
Remove --offline empty index error. This reverts the error added in #6871 which attempts to provide a "nicer" error message if `--offline` is used with an empty index. I was concerned about false positives, and sure enough someone found one. If all deps are patched, it is OK for the index to be empty, because the resolver will just use the patched entries. I considered trying to move the error to another location, but I think it would require significant changes to the registry API (which is already hard to follow). I figure the "not found" error message is good enough with the "don't use --offline" hint. Closes #7582
This includes the following:
Move offline tests to a dedicated file.
If an index has never been downloaded, and
-Z offlineis used, provide a suggestion to run without-Z offline.If an index needs to be updated, and the network appears to be down, suggest running with(removed this)-Z offline.The
offline_resolve_optional_failtest is added to show that resolver errors are still possible (though hopefully rare!).