Allow to generate lockfile without registry update

[matklad]

Attempt to fix #3479.

This particular implementation is quite probably broken, because there are no tests yet, I am planning to add them later :)

I really like how this features solves #1882 nicely: if you don't have internet connection, you can still add new dependencies, but you need to be super explicit about it.

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Thanks for the PR @matklad! As you could probably have predicted I have a number of thoughts about this feature :)

• We may not wish to call this --offline because Cargo will still attempt to download crates from the network (e.g. if there's a lock file that and the index is up to date). This also doesn't touch the handling of git repositories, so we'll still update/fetch those even if there's a cached copy locally.
• I worry that we don't have enough corresponding tools to update the registry. For example we don't have a "cargo update registries" command or a "cargo fetch git repos" command.
• This likely wants to change some error messages to indicate "you passed --offline and this may succeed with this flag not being passed"
• The current behavior has actually led to uncovering a number of bugs mentioned in use cases of Add the ability to ignore registry-lookup failures #1882. It's tough to eek out the scenario sometimes behind 'ZOMG WTF CARGO DOWNLOAD TOO MUCH' but often there's a kernel of a situation that's best handled without an --offline flag (or something similar.

Overall this feels like a relatively niche use case which has a high likelihood for being misused unfortunately. To take advantage of this you'd need to:

• Somehow make sure that your local copy of the index is "up to date" for your own definition of up to date. We don't give many tools to manage this though?
• Know that you don't touch any git repositories or other registries.
• Know that you've pre-downloaded all your crates from crates.io somehow (unsure how)

Overall I've tended to felt that we didn't quite have a killer use case for this flag just yet (or a great name for it). I'd love to continue exploring though and seeing what we can come up with!

[matklad]

Yeah, I totally understand that it's not clear at all if this is a desirable feature or not.

First of all, --offline is really a terrible name, it should be --no-index-update instead, and do just that.

The problem I want to solve with this feature is: "Without internet, it should be possible to start a new Rust project with dependencies, as long as you do have (accidentally) the necessary dependencies in ~/.cargo". This seems a problem worth solving to me, but I am biased because I've had connectivity problems just recently :)

What I like about this solution is that it is non-invasive: you don't add an --offline flag to every cargo command, you just delimit very specific step (lockfile generation) where you ask Cargo not to connect to the internet.

I worry that we don't have enough corresponding tools to update the registry.

We don't have explicit tools to do that, but just generating lockfile without this flag should do this trick? Also, one can upload a binary to crates.io which depends on 500 most popular crates, and then it should be possible to cargo install hermit before going to the internet-less area :)

This likely wants to change some error messages to indicate "you passed --offline and this may succeed with this flag not being passed"

This would be nice to have, but I think not mandatory (except for the case "index is corrupted/does not exist, and I can't update it"). Because it is restricted to an explicit cargo generate-lockfile, it should be clear what's going on anyway. And advising not to pass --no-index-update is not really useful, because if you use this flag, there must be a reason for it :)

The current behavior has actually led to uncovering a number of bugs mentioned ...

About bug uncovering, this feature does not change any codepaths outside of cargo generate-lockfile, so it should not affect any bugs :) About "is this flag a proper solution for a problem at hand", I am mainly aiming at the problem described at the beginning of the comment.

Overall this feels like a relatively niche use case which has a high likelihood for being misused unfortunately

Agree here. The question is, how big is the niche (I remember a few annoyed people, who are unable to start a rust project offline) :)

To sum up: the main improvement over previous suggestions in #1882 is that we are able to make the scope of the feature really narrow.

[bors]

☔ The latest upstream changes (presumably #3893) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Guh sorry it took me awhile to get back to this!

It's true yeah that you can just generate a Cargo.lock which depends on lots of crates, but I'd find that somewhat non-obvious and you typically have a target in mind to work on beforehand. I unfortunately though don't really know what the commands would look like to manage an offline cache.

I also personally feel that the error message here is critical to this feature. Whatever we name this flag the history of issues filed that think they want this flag indicates that it will be very commonly misconstrued as to its purpose. In that sense I believe errors need to be very clear about "this flag was passed, things may break". Otherwise my hunch is that we will start receiving a torrent of bug reports on Cargo (or worse, random crates throughout the ecosystem) about the "odd behavior" of this flag. The error message is in my mind an attempt to head off those reports and resolve confusion more quickly.

Ah and for the bugs I meant moreso in the resolver itself. I don't think this is a buggy implementation, but historically the resolver has been buggy by asking for an index update when it didn't really need to.

[matklad]

Okey! When in doubt, leave it out! Let's close this then because this flag can indeed be misused, even with error messages. Nevertheless, I like the idea of limiting the scope of this feature to generate-lockfile, so if we were to implement it eventually, it would be a proper approach I think.

[alexcrichton]

Yeah that sounds plausible to me, having a targeted implementation!