-
Notifications
You must be signed in to change notification settings - Fork 31
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 comments to documentation #22
Comments
While I like this idea, I'm not sure if this is easily possible to do in code, even if it is it doesn't seem like a good idea to hardcode documentation as strings in the binary. Instead I suggest keeping a default configuration file with comments in the repository and packaging it with releases. The authentication tokens and keys would have to be stored somewhere else, but maybe this should be the case anyway. This also gives us the opportunity rethink the idea of explicitly initializing the configuration file through lucid. If a default configuration is packaged with releases there shouldn't be a need to create one when running Lucid for the first time. The only thing that should have to be generated is authentication data, because it doesn't have a good default. I also had another thought when looking at the way configuration is handled: The server and the interactive cli are the same binary. |
It's a good idea on the paper, just some points are important. Lucid is build to be a DevOps software, running with some Linux standards, with So pack a default configuration file in the release zip is not a bad idea but we also need to keep the If we deploy Lucid on Linux package managers maybe we could add default configuration with comments and not in the GitHub releases. The init command is important for me to bootstrap the Lucid instance very quickly, some programs like About the CLI, I want to keep a single binary BUT you right on many points! Firstly, if you look at this line, the actual CLI is thought (but not coded) as a way to manage lucid nodes, not only the local node but each node, maybe we could make a new API endpoint like |
Keeping the Splitting Lucid into server and cli binaries isn't necessary to implement any feature, but would decouple two parts of Lucid that shouldn't directly interact with each other (only using api endpoints), so it's mainly for code quality reasons. I think I'll test some of this on my fork to see if it would bring significant enough improvements to be worth it. |
The For the CLI and the server decoupled, I'm really for it and it's the idea [from the begining], in fact, the CLI is only an HTTP client. Feel free to achieve this, If you use an HTTP library maybe you could don't use |
I think it could be cool to have comments in documentation!
Issue Opened on serde_yaml Github: dtolnay/serde-yaml#145
The text was updated successfully, but these errors were encountered: