Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Discuss better CLI parsing / startup-options #271

Open
sonicfromnewyoke opened this issue Sep 10, 2024 · 4 comments
Open

Discuss better CLI parsing / startup-options #271

sonicfromnewyoke opened this issue Sep 10, 2024 · 4 comments

Comments

@sonicfromnewyoke
Copy link
Contributor

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

  • zig-clap which was built with a reference to the original clap from the rust's world
  • zig-args - simple-to-use argument parser with struct-based config
  • yazap - brand-new zig library for building seamless (in authors opinion) cli-apps

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

#!/bin/sh
STARTUP_OPTS="..."
ENTRYPOINT_OPTS="..."
RPC_OPTS="..."
// ....
FINAL="$STARTUP_OPTS $ENTRYPOINT_OPTS $RPC_OPTS ..."

exec agave-validator $FINAL

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-layout

Additional Context

No response
@InKryption
Copy link
Contributor

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.

@Sobeston
Copy link
Contributor

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.

@0xNineteen
Copy link
Contributor

im pro config files too

@sonicfromnewyoke
Copy link
Contributor Author

ok, it's been a while to vote, and now we have the next picture:

  • CLI parsing
  • YAML
  • TOML
  • JSON (with possible migration to ziggy)
  • Zig struct (similar to build.zig.zon)

only a few libraries help to parse toml files in zig ecosystem, and all of them have issues.
I, personally, would prefer using native struct or JSON because both of them have first-class support from the language itself.

Anyway, this week I'll have some bandwidth to start implementing that feature, and I'm going to start by creating a config struct (which is not dependent on config-file ext).

I believe we will agree on a config-file extension during the first step of implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
Sig
Status: 📋 Backlog
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Sobeston @InKryption @0xNineteen @sonicfromnewyoke