Conversation
Jarkko Sakkinen
jarkko
I first used clap in tpm2sh, then switched to lexopt and again back to clap because of too much boilerplate code.
The problem I run every single time with clap is how hard it is to control if you actually want to control in detail.
Now I found the ultimate compromise for my situation:
1. I pre-rendered from clap usage and help to usage.txt and help.txt for each subcommand.
2. I changed my subcommands as directories. E.g., from "create-primary.rs" to "create-primary/mod.rs".
3. I deployed the text files to associated directories.
4. Finally I migrated parsing back lexopt.
Intial commit:
59 files changed, 538 insertions(+), 521 deletions(-)
Not too bad. WIth only parsing is just super complicated tool to do that task, or more complicated than necessary, and lexopt adds visibility to code paths so it is overall much more maintainable :-)
Also few redundant edits every once in a while to two txt files per subcommand is IMHO much more maintainable than adjusting generation from the source code.
The problem I run every single time with clap is how hard it is to control if you actually want to control in detail.
Now I found the ultimate compromise for my situation:
1. I pre-rendered from clap usage and help to usage.txt and help.txt for each subcommand.
2. I changed my subcommands as directories. E.g., from "create-primary.rs" to "create-primary/mod.rs".
3. I deployed the text files to associated directories.
4. Finally I migrated parsing back lexopt.
Intial commit:
59 files changed, 538 insertions(+), 521 deletions(-)
Not too bad. WIth only parsing is just super complicated tool to do that task, or more complicated than necessary, and lexopt adds visibility to code paths so it is overall much more maintainable :-)
Also few redundant edits every once in a while to two txt files per subcommand is IMHO much more maintainable than adjusting generation from the source code.
1
0
0