Open sonicfromnewyoke opened 1 week ago
Personally, not a fan of YAML - my vote is against that. As a side note, and this doesn't entail any promise of anything, but I am working on a personal project where the CLI parser is based on a markdown file which would act both as the help string and as the template. If I get that up and running I'd like to pitch it, but otherwise the options outlined here (aside from YAML) seem good to me.
Ziggy does seem super cool. I asked Loris on his (super unbiased) opinion on using Ziggy, and he suggested starting with JSON or something and then switching to Ziggy later once he's done another design pass; we might not want to beta test it.
Problem
I'd like to discuss that https://github.com/orgs/Syndica/projects/2/views/1?pane=issue&itemId=47708039 in the proposal.
there are a couple of libraries in zig ecosystem for writing CLI applications
Proposal
to discuss the pros and cons of each library which were listed above and choose the best one
However, I, personally ,would prefer to parse yaml/toml config file, as it was done in the firedancer
Because It's tedious to pass 20+ node options to start-up the script. And, IMO, it's easier to specify all the configurations grouped by labels, and
yaml
/toml
config is more convenient for that.yes, you can say something like: "this is a skill issue" and reference to shell-script like the following
or something similar with templates
Alternatives
as an alternative to
yaml
/toml
config file, we can discuss ziggy - a zig-based schema language that can validate your config against data-layoutAdditional Context
No response