`Cargo.lock` and dependency resolution

[ehuss]

This issue is for working through the implementation issues with locked dependencies.

It is almost certain that the standard library will need to be built with the exact same dependencies used in the release. That is, dependencies like libc will not be allowed to "float" to the most recent release. All dependencies will also be built separately from the user's project, so if the user has a dependency on libc, it will be built separately from the libc for the standard library (which may be the same or different version). Metadata tricks are used to link these properly.

The rust-src rustup component includes the standard library sources, but does not include dependencies. It includes the Cargo.lock file, from which we can infer the dependency versions.

I'm not certain at this time what problems this might present.

[alexcrichton]

One other reason I think we need to lock dependencies is for determinism. Or well I think that we should provide a way to have deterministic builds of the standard library (no floating deps over time) and unless we store more information in project lock files (which I'm not sure is feasible) then using the rust lock file would solve this issue

[SimonSapin]

All dependencies will also be built separately from the user's project, so if the user has a dependency on libc, it will be built separately from the libc for the standard library

This could be represented in Cargo’s resolution as a separate "source", for example std+registry+https://github.com/rust-lang/crates.io-index instead of registry+https://github.com/rust-lang/crates.io-index.

[Ericson2314]

Hmm there's two issues at play: making the depedencies not "float" and making them not conflict with the users dependencies. For the latter, we can and should use private dependencies. They are *exactly" what we need, and will also help us catch the standard library leaking implementation details. For the former one can just pin exact versions from the stdlib Cargo.toml? Remember with different features/platform combinations, the exact dependencies of std and friends can change.

[Eh2406]

Um... That is not what private dependencies do according to the current RFC. Private dependencies are just as locked to the rest of the dependency tree as the current "unspecified" dependencies. IE only one global use of each links and no two semver compatible versions.

[Ericson2314]

no two semver compatible versions.

Well that is silly. Private dependencies should never unify (i.e. even if we use the same libc it should show up as if we used two different ones so we cannot accidentally mix them together.) Therefore maybe Cargo can prefer to user fewer versions, but if std depends on an exact version and something else another exact version, the build plan should still go through.

[Eh2406]

That is an interesting thought, probably worth discussing a new RFC for that, but for now that is not what "private dependencies" does. So we will need to do something special for std.

[Ericson2314]

Well for the MVP we don't. I personally think this is a minor tweak to that RFC so I'll comment in that issue, and see what people say.