Need guidance on how to document cargo features #43
Replies: 8 comments 4 replies
|
One option is what I do in Serde - document them in Cargo.toml. Though we also have a page on the website so there is some duplication. Maybe rustdoc would be more appropriate? This could also be a feature request for rustdoc: generate documentation for features using comments in Cargo.toml. Definitely rustdoc should mention what features need to be enabled to get a particular API. If I am looking at rustdoc of a function, right there it should say this function requires feature so-and-so. |
|
Hi I wanted to post directly on libz blitz thread but I see that this feature is already open. While working on rust-lang/log#125 I've discovered that log makes an arguably insufficient attempt to document its "crate feature flags" in master:
Some crates like ndarray make a stellar job of documenting the "crate feature flags". I would suggest using ndarray's approach with rustdoc as a template (even if this information would be discoverable via Cargo.toml). Imho documenting all (default and optional) feature flags with their consequences should be required. This might be handled on docs.rs side with gathering the information into a separate page. |
|
Any progress on this? I'd love to see it easier to find out what features might interest me when I look at a given crate, and I'd like to be able to provide this information in my own documentation (with maximal automatic checking). |
|
This would be great...
Maybe rustdoc could pick up on |
|
Docs.rs recently started displaying these in the 'feature flags' section: https://docs.rs/crate/bytecheck/0.2.0/features |
|
I made a crate for documenting the feature as comments in the Cargo.toml: https://docs.rs/document-features |
|
/cc @GuillaumeGomez This would be a nice rustdoc feature, I guess. |
|
There is a related RFC for adding feature docs in |
Uh oh!
There was an error while loading. Please reload this page.
Today figuring out what cargo features exist and what they do generally means navigating the project source and inspecting the toml file. That's a pretty bad experience. Need a standard way to expose this information.
All reactions