Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
initial cargo-plugin-fields RFC. #2776
I think it's probably best to close this for now, While it could be resurrected in the form of json-ld which explains the differences between the metadata keys, and the
A better way to achieve this explanation is to first implement the json-ld semantics for Cargo.toml, without adding any new features or user facing changes to cargo.
Once that is out of the way it'll be easier to see how these
Thanks for writing this up! I think that extending Cargo and making it easy to incorporate rust into larger multi-language build systems are both important and interesting use cases, so I'm glad to see people thinking along these lines. I also think that these problems are really tricky, given the extremely broad range of use cases and stakeholders. All that is just to say that I would like to have a really clear understanding of the intended use cases for this type of proposal. Reading through this, I'm finding myself a little unclear about how this additional data might be consumed. Would it be expected that Cargo would provide this data to build scripts? Or is it intended to be indexed by crates.io in some way?
I think it would be really helpful if you could add descriptions of intended use cases. Even if this RFC doesn't end up being accepted, having a better understanding of what you're wanting to accomplish might also help inform future RFCs.
@psFried I'm not exactly sure how the tooling is going to end up at this point,
That is currently the extent of my plans for it, The plugin fields would come with their own context,
Additionally they can add their own contexts, so for instance:
Exactly how this mechanism interfaces with the general cargo plugin mechanism, is kind of less important to me, than ensuring that under the hood it is all nicely typed, and plays well with others!
Beyond tools which consume and process the information as streams described above,
The primary non-stream use case i'm after is being able to specify lints on dependencies and transitive dependencies, storing that information directly in Cargo.toml, and all the various checks that are run by the CI, so that CI and contributors can both run the same plugin/sets of commands locally and easily keep them in sync.
The exact mechanism for integration of TOML and how the mapping from fields to contexts at the moment is needed to be thought about. But a very important detail, is that cargo needs to ensure that the fields which it defines, conform to the context in the way it is defined.