-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add chapter on describing config types #166
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
# Rendering documentation for your Configuration | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you open a discussion for us to discuss this first? There are a lot of potential directions to go and I tend to prefer the solution discover to happen in issues as PRs are more likely to come and go. |
||
|
||
If your application offers extensive configuration options, you may want to | ||
render these for the conveniance of the user. | ||
|
||
You could render them straight to the terminal, so that a user can "ask" your | ||
app what configuration it provides: | ||
|
||
```commandline | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: we tend to use |
||
myapp print-config-options | ||
``` | ||
|
||
Using the [type_description crate](https://crates.io/crates/type_description) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should update the list of referenced crates at the end of the book |
||
you can annotate your configuration struct(s) and let Rust do the magic: | ||
|
||
```rust,ignore | ||
use type_description::AsTypeDescription; | ||
use type_description::TypeDescription; | ||
use type_description::TypeKind; | ||
use type_description::Sign; | ||
|
||
/// A configuration | ||
#[derive(TypeDescription)] | ||
struct Config { | ||
/// The bind address | ||
addr: std::net::SocketAddr, | ||
|
||
/// The Port | ||
port: u16, | ||
} | ||
``` | ||
|
||
Comment on lines
+16
to
+32
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All code samples should be extracted from full programs that we compile in CI and can be run. |
||
The derive macro implements the `AsTypeDescription` on your `Config` type and | ||
uses the comments as descriptions. | ||
|
||
The `type_description` crate also implements the `AsTypeDescription` trait for | ||
the most common types for configuration from the standard library, such as | ||
numbers, `bool`, `String`, but also `Option`, `Vec` or `HashMap`. | ||
|
||
You can then use `Config::as_type_description()` to get the description for your | ||
`Config` type. | ||
|
||
You can render this information to a web-page, pdf, or simply to text and | ||
print it on the commandline (render functionality | ||
[within the type_description crate is currently unreleased](https://github.com/TheNeikos/type_description/blob/master/src/render.rs#L70)). | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you feel is the line for this being in the CLI documentation vs being in its own page?