-
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?
Add chapter on describing config types #166
Conversation
Signed-off-by: Matthias Beyer <[email protected]>
@@ -0,0 +1,46 @@ | |||
# Rendering documentation for your Configuration |
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.
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.
- [Rendering documentation for your CLI apps](./in-depth/docs.md) | ||
- [Rendering documentation for your Configuration](./in-depth/render-configuration.md) |
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?
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 comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we tend to use console
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 comment
The 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
```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, | ||
} | ||
``` | ||
|
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.
All code samples should be extracted from full programs that we compile in CI and can be run.
This is a bit of a shameless self-plug. The mentioned
type_description
crate was a by-product of some work @TheNeikos and I have done and we've used it already to do exactly what the article describes.Maybe @TheNeikos wants to add some comments before this gets considered, so this goes as draft for now.