Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Consistent cli #14
I honestly don't see the point of the first commit. If the goal is to have multiple sub-commands then they should be parsed out in the binary and there should be multiple entry points in the library instead of feeding it all into a
run() function in the library and having it parse options again. This makes the code much more testable. Half the changes in this commit focuses on functionality that's removed in the very next commit. This commit is dense and could have a few commits:
- add colorized help for a better user experience
- remove unnecessary
- multiple entry points
The second commit is very dense that could honestly be broken up into a few logical pieces. But ultimately it breaks fallback cases and produces invalid ebuilds without reporting anything to the user.
- code style changes
- cargo -> cargo_metadata
The third commit starts using the
log crate to let the user know that the ebuild is now invalid but still causes success to be returned back to the user. Overall if we're going to produce an invalid ebuild then we should immediately stop and error out and not exit with a ret code of 0.
I don't agree with your idea of apis, I like to have a single run function that can handle all the commands and options. Most of the tools in rust that I saw use that logic and I tried to be close to that. Specially because there are multiple features that I want to add in future.
The log is used to warn that some fields in the manifest were missing. Anyway as user I still want have the ebuild generated to be able to fix it by hand or investigate better.
First patch doesn't do what it intends and the other change contained (and not mentioned in the commit message) has an unintended consequence of breaking the help output.