-
Notifications
You must be signed in to change notification settings - Fork 800
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
Config file #2808
Config file #2808
Conversation
…nfig-file � Conflicts: � Cargo.lock � beacon_node/src/cli.rs � boot_node/Cargo.toml � boot_node/src/lib.rs
…nfig-file � Conflicts: � Cargo.lock � beacon_node/src/cli.rs � boot_node/src/config.rs � boot_node/src/lib.rs � common/clap_utils/Cargo.toml � lcli/src/main.rs � lighthouse/src/main.rs � validator_client/Cargo.toml
.visible_aliases(&["b", "bn", "beacon"]) | ||
.version(crate_version!()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is no longer available in clap
do we want an alternative? I didn't think crate-level versions seemed really relevant
.author("Sigma Prime <[email protected]>") | ||
.setting(clap::AppSettings::ColoredHelp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed this because this is now the default setting
…nfig-file � Conflicts: � beacon_node/src/cli.rs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested this out manually with different combinations of cli and config file parameters and it works as expected :)
I wasn't super happy about parsing the parameters twice, but couldn't come up with anything substantively better after spending quite a lot of time with clap
.
Another potential design is to use the clap derive feature to create Config
structs.
I have a small self-contained example here. The example parses a Config
struct which derives clap::Parser
and then updates it with additional parameters from the config file.
https://gist.github.com/pawanjay176/0239b7bb80c2244a60216523654df92c
The derive feature seems to contain everything we currently have and is a bit cleaner than the App::new().arg(...)
type builder pattern imo. I haven't fully checked if this pattern would give us further issues when used with subcommands, but seems like it should work fine. It would be a substantial refactor though.
common/clap_utils/src/lib.rs
Outdated
.map(toml_value_to_string) | ||
.collect::<Result<Vec<_>, _>>()? | ||
.join(","), | ||
TomlValue::Table(_) => return Err("Unable to parse YAML table".to_string()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TomlValue::Table(_) => return Err("Unable to parse YAML table".to_string()), | |
TomlValue::Table(_) => return Err("Unable to parse TOML table".to_string()), |
common/clap_utils/src/lib.rs
Outdated
.map(yaml_value_to_string) | ||
.collect::<Result<Vec<_>, _>>()? | ||
.join(","), | ||
YamlValue::Mapping(_) => return Err("Unable to parse TOML table".to_string()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YamlValue::Mapping(_) => return Err("Unable to parse TOML table".to_string()), | |
YamlValue::Mapping(_) => return Err("Unable to parse YAML table".to_string()), |
book/src/file-config.md
Outdated
``` | ||
Would be equivalent to this YAML config: | ||
```bash | ||
$ lighthouse --config-file ./beacon-config.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ lighthouse --config-file ./beacon-config.yaml | |
$ lighthouse beacon_node --config-file ./beacon-config.yaml |
book/src/file-config.md
Outdated
``` | ||
And this TOML config: | ||
```bash | ||
$ lighthouse --config-file ./beacon-config.toml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ lighthouse --config-file ./beacon-config.toml | |
$ lighthouse beacon_node --config-file ./beacon-config.toml |
Co-authored-by: Divma <[email protected]>
Co-authored-by: Divma <[email protected]>
Co-authored-by: Divma <[email protected]>
Co-authored-by: Divma <[email protected]>
Co-authored-by: Divma <[email protected]>
really digging the new link checker! It already helped me find a problem here thanks @ackintosh ! |
@divagant-martian this is the difff for most of your feedback: https://github.com/sigp/lighthouse/compare/a23f0424a33da6a0918924b3e6be71a4f36babfe..9930a278965f269eb823fc427e532d173f0458c6 This is a diff for some doc and formatting fixes/updates: https://github.com/sigp/lighthouse/compare/0ae7ae5ece1cb88d44b49b3eaf03b15618870dbb..80a54e52c984599a2011f363a60ddaecf027baa5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @pawanjay176 in attempting a version .2 that leverages structopt, but this change looks good to me as is right now :)
This reverts commit c14d255.
…nfig-file # Conflicts: # account_manager/src/validator/exit.rs # lighthouse/src/main.rs
I am working on the migration to clap derive here: #3007 So I'm guessing we will end up closing this PR and working off of that one with something like what Pawan suggested. |
I suggest then if you can, to limit this PR only to the standarization of flags. That's a lot of work that we can merge anyway |
Closing for #3079 |
Issue Addressed
Resolves: #2748
Proposed Changes
Added some docs here with some info, there are a couple of quirks.
clap
to3.0.4
beacon_node
,validator_client
, andboot_node
subcommands for now though. I sort of needed to do this in order to add a layer of validation to config we load from a file. Using the workaround described below, config values provided from file for the wrong subcommand or that are just entirely foreign would silently fail. So I needed the constants to get an idea of all available flags for each subcommand. Seems like we could use these sets of known flags to generate tests like our existing CLI tests. It's a bit tricky to remember to add to those when adding a new flag.Additional Info
I was able to figure out how to do this within
clap
with some workarounds.env::args_os()
)cli::App
with all of lighthouse's commands and flags.App
(this also consumes cli args) and get back matched arguments--config-file
flag.--config-file
flag. If it exists, read from the file.cli::App
instance, but as the args are being set, set an additionaldefault_value
equal to the matching file config value. This way lighthouse only uses file config value if the value is not passed in via CLI. If the arg has an existingdefault_value
, the latest setdefault_value
takes precedence, so the file config would take precedence over the lighthouse-defined default. This behavior makes sense to me.Relevant
clap
issuesargfile
support might be included in v3.1 Add argfile support clap-rs/clap#1693Todo: