build-std: context #3
Conversation
Co-authored-by: Adam Gemmell <[email protected]>
| [Cargo registries][cargo-docs-registry], like crates.io, are centralised sources | ||
| for crates. A registry's index is the interface between Cargo and the registry | ||
| that Cargo queries to know which crates are available, what their dependencies | ||
| are, etc. crates.io's registry index is a Git repository - | ||
| [rust-lang/crates.io-index] - which is updated automatically by crates.io when | ||
| crates are published, yanked, etc. Cargo can query registries using a Git | ||
| protocol which caches the registry on disk, or using a sparse protocol which | ||
| exposes the index over HTTP and allows Cargo to avoid Cargo having a local copy | ||
| of the whole index, which has become quite large for crates.io. | ||
|
|
||
| Each crate in the registry has a JSON file, following | ||
| [a defined schema][cargo-json-schema]. Crates may refer to those in other | ||
| registries, but all non-`path`/`git` crates in the dependency graph must exist | ||
| in a registry. As the registry index drives the building of Cargo's dependency | ||
| graph, all crates that end up in the dependency graph must be present a | ||
| registry. |
There was a problem hiding this comment.
Whats not clear to me is what the intent of this section is
There was a problem hiding this comment.
In our later drafts relating to explicit dependencies on the standard library, we got feedback from @ehuss that the Cargo registry schema may need to be updated to know about these explicit dependencies, and so given that we then mention the Cargo registry in the later drafts, we introduce it here in the background section.
I can explain why it is present in the document if you'd like. So far I've err'd on the side of taking the context-related content and presenting it as-is with only the strictly necessary changes to ensure it makes sense divorced from what it is providing context for.
There was a problem hiding this comment.
The downside to not mentioning intent is it can make it hard to know what content is relevant to include. Knowing this is about "if you want to add new dependency types to published packages, here is what you need to know" helped to uncover other information (and impact on other teams)
There was a problem hiding this comment.
Yeah, that's fair enough. It's a trade-off between not writing additional content that isn't as useful once a proposal is added to this, and allowing these early context parts to be entirely standalone. I'm happy to adjust and mention intent more in these sections.
davidtwco
force-pushed
the
build-std-context
branch
from
a1063dc to
396138b
Compare
|
Closing in favour of #4 |
3 participants
This document is split out from a larger proposal being drafted for build-std. It is aimed at giving the reader all the context they'll need to understand the history of proposals for build-std, the current unstable implementation, how relevant and affected parts of the Rust toolchain currently work and what users have wanted build-std to solve for them.
solution to
I'm looking for feedback on where this falls short in helping a potential reviewer of a full build-std proposal in understanding what could eventually be proposed, the problems being solved and the considerations involved. How build-std should actually end up working is out-of-scope.
In the literature review appendix, content is written to reflect the facts as described in the source material. If something that was written in those has since changed, the document doesn't reflect that, it just describes what was written in the source material. Anything that has changed since the sources were written should be described somewhere else in the document.
Rendered