build-std: explicit dependencies#3875
Conversation
davidtwco
added
T-cargo
| ### Why add standard library crates to Cargo's index? | ||
| [rationale-cargo-index]: #why-add-standard-library-crates-to-cargos-index | ||
|
|
||
| When Cargo builds the dependency graph, it is driven by the index (not | ||
| `Cargo.toml`), so builtin dependencies need to be included in the index. |
There was a problem hiding this comment.
Is this about adding them to the index (as top-level packages), which isn't needed, or adding dependencies on the standard library to the index format?
There was a problem hiding this comment.
Still not clear to me why they need to be in the index
There was a problem hiding this comment.
This was my understanding from @ehuss's earlier feedback but maybe I've misunderstood it?
There was a problem hiding this comment.
I'm not sure if this resolved your concern but given it's been a few weeks, I'll resolve this conversation thread so it's easier to keep track of what I still need to address. Feel free to reopen or start another thread.
There was a problem hiding this comment.
from the crates.io perspective, if the cargo team finds a way to make this work without index changes, then I think we'd prefer that. I don't think we have any major blockers with the proposed solution either, but if we can simplify it to not need index changes then even better.
since this discussion is apparently still ongoing I'll delay my FCP approval for now until I know what solution we ultimately will choose :)
|
@rfcbot fcp concern redundant-no-std See #3875 (comment) |
|
@rfcbot fcp resolve redundant-no-std |
| ### Should we support `build-dependencies`? | ||
| [unresolved-build-deps]: #should-we-support-build-dependencies | ||
|
|
||
| Allowing `builtin` dependencies to be used in `dependencies` and | ||
| `dev-dependencies` but not in `build-dependencies` is an inconsistency. | ||
|
|
||
| However, supporting `builtin` dependencies in `build-dependencies` would permit | ||
| no-std build scripts. It is unclear whether supporting no-std build scripts | ||
| would be desirable. |
There was a problem hiding this comment.
We should call out that the current behavior is a safe default because to change it is to turn an error case into a success case, making this a two-way door
| ### Should `cargo metadata` include the standard library's dependencies? | ||
| [unresolved-cargo-metadata]: #should-cargo-metadata-include-the-standard-librarys-dependencies | ||
|
|
||
| `cargo metadata` is used by tools like rust-analyzer to determine the entire | ||
| crate graph and would benefit from knowledge of the standard library's | ||
| dependencies, but this leaks internal details of the standard library and is | ||
| counter to the intent behind opaque dependencies. |
There was a problem hiding this comment.
Can we expand that the main concern for doing this is compatibility but
cargo pkgidandcargo build --message-formatwill unconditionally use the new pkgid speccargo_metadatadoes not currently parse the pkgid spec so this won't break all users- this will also show up in the source which is still opaque and
cargo_metadatadoes not parse
So this is only a problem for users who are parsing pkgid specs using cargo-util-schemas or their own parser. The scope of that is likely small enough to not be too disruptive.
There was a problem hiding this comment.
Crater uses cargo-util-schemas to parse pkgid specs1.
Edit: Though failing to parse std internal dependencies shouldn't be a problem for crater.
Footnotes
14 participants
Allow users to add explicit dependencies on standard library crates in the
Cargo.toml. This enables Cargo to determine which standard library crates are required by the crate graph withoutbuild-std-cratesbeing set and for different crates to require different standard library crates.This RFC is is part of the build-std project goal and a series of build-std RFCs:
build-std="always"(build-std: always #3874)build-std="compatible"(RFC not opened yet)build-std="match-profile"(RFC not opened yet)There is also a Zulip channel where you can ask questions about any of the build-std RFCs. This series of RFCs was drafted over many months with the help of stakeholders from many Rust project teams, we thank them for their help!
There are some details that have been noted as being worth mentioning in any eventual tracking issues:
FCP
Rendered