Consider doing a forced lock of the standard library.

[ehuss]

It might be a good idea to do the equivalent of --locked for the standard library to ensure that the Cargo.lock isn't modified, and that it is correct.

[alexcrichton]

I agree with this in spirit, but --locked probably won't work "as is" because we are actually technically vastly changing the previous lock file by deleting most nodes from it (e.g. everything related to the compiler/tools/etc). In that sense we want an assertion that the final crate graph is a subset of the original crate graph, but that's not precisely what --locked is doing.

Either way, agreed would be good to implement!

[adamgemmell]

I think it might make more sense to do this in a cargo test. I'm not sure what user configuration could break this behaviour (patching dependencies, and ignoring the lockfile with cargo install don't work). The only thing that might change this is if the same workspace was used and the lockfiles combined, but then Alex's proposal wouldn't work.

[weihanglo]

With rust-lang/rust#128534 and rust-lang/cargo#14358, it is possible to implement the --locked behavior in -Zbuild-std.

[adamgemmell]

This would remove the need for rust-lang/cargo#13916, correct? My understanding is that we'd still end up with a subset of the original lockfile but can actually use the lockfile on disk now, making the checks unnecessary.

[weihanglo]

Yes. I'll close that one. Thank you for taking care of it.
We still need to implement the actual --locked behavior to -Zbuild-std. See rust-lang/cargo#14358 (comment). I am think that Workspace can have a field additionally check if Cargo is about to write a new lockfile, it bails out.
https://github.com/rust-lang/cargo/blob/2cd657cc33a46ac026154534d5b6fac264acd15b/src/cargo/ops/lockfile.rs#L40-L65

[weihanglo]

I think it might make more sense to do this in a cargo test. I'm not sure what user configuration could break this behaviour (patching dependencies, and ignoring the lockfile with cargo install don't work). The only thing that might change this is if the same workspace was used and the lockfiles combined, but then Alex's proposal wouldn't work.

It indeed breaks [patch]. You can pull rust-lang/cargo@4e7dfb1 and check with the reproduction in rust-lang/cargo#14003.
One can argue that if patches are needed, clone rust-lang/rust repo and do patches in the source, though that is kinda inconvenient. So I think unconditionally banning lockfile writes might not be the best solution.

Cargo recently got the --lockfile-path unstable flag. We could potentially combine this and patch if people want to patch std dependencies. I am not sure what the UI would look like though.

[bjorn3]

Cargo has an internal env var to specify the location to search for the standard library sources. Maybe everyone who wants to patch the standard library or it's dependencies could be made to use this env var and only force --frozen when not using this env var. That would also allow keeping the [patch] section for the standard library in the standard library workspace rather than mixing it into the user project workspace, which also should fix rust-lang/cargo#14003. In any case I don't think stable cargo should ever allow [patch] in the user workspace to apply to the standard library as no guarantees whatsoever are provided on what dependencies (and versions of said dependencies) the standard library uses and the patch may break things with future versions of the standard library.

[glandium]

vendoring is another thing that makes things go wrong with build-std.

[bjorn3]

In what way do you mean?

[glandium]

Cargo fails to find the std dependencies, starting with compiler_builtins.

[adamgemmell]

If it's not related to --locked behaviour then that sounds like its covered by #23