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.

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

Implement Correct Usage Flags for forest and forest-cli #2175

Closed

Conversation

jdjaustin
Copy link
Contributor

@jdjaustin jdjaustin commented Nov 10, 2022

Summary of changes
Changes introduced in this pull request:

  • Change flags available for forest and forest-cli to only those that make sense and are usable.

Reference issue to close (if applicable)

Closes associated tasks in issue #2076

Other information and links

Task to change the config dump behavior will be covered under a separate PR.

@jdjaustin jdjaustin changed the title [WIP] Implement Correct Usage Flags for forest and forest-cli Implement Correct Usage Flags for forest and forest-cli Nov 16, 2022
@jdjaustin jdjaustin marked this pull request as ready for review November 16, 2022 16:16
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@lemmih lemmih left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Getting closer. You still need to review all the cli options, though. It's not too difficult to see if a command-line option is used or not. You can either use git grep or simply delete the field and see what breaks.

forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@lemmih lemmih left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot more that can be done to clean up the command-line handling for forest and forest-cli but this is a good start.

forest/shared/src/cli/mod.rs Show resolved Hide resolved
forest/shared/src/cli/mod.rs Outdated Show resolved Hide resolved
Comment on lines +33 to +35
/// A TOML file containing relevant configurations
#[structopt(short, long)]
pub config: Option<String>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to take this opportunity and change Option<String> to Option<PathBuf>. Better-typed variables are better than comments saying that this should be a path.

Comment on lines +42 to +44
/// Address used for metrics collection server. By defaults binds on localhost on port 6116.
#[structopt(long)]
pub metrics_address: Option<SocketAddr>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we use it anywhere in the forest-cli unless I'm missing something.

Suggested change
/// Address used for metrics collection server. By defaults binds on localhost on port 6116.
#[structopt(long)]
pub metrics_address: Option<SocketAddr>,

Comment on lines +55 to +61
// env_logger-0.7 can only redirect to stderr or stdout. Version 0.9 can redirect to a file.
// However, we cannot upgrade to version 0.9 because pretty_env_logger depends on version 0.7
// and hasn't been updated in quite a while. See https://github.com/seanmonstar/pretty-env-logger/issues/52
// #[structopt(
// help = "Specify a filename into which logging should be appended"
// )]
// pub log_file: Option<PathBuf>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// env_logger-0.7 can only redirect to stderr or stdout. Version 0.9 can redirect to a file.
// However, we cannot upgrade to version 0.9 because pretty_env_logger depends on version 0.7
// and hasn't been updated in quite a while. See https://github.com/seanmonstar/pretty-env-logger/issues/52
// #[structopt(
// help = "Specify a filename into which logging should be appended"
// )]
// pub log_file: Option<PathBuf>,


impl CliOpts {
pub fn to_config(&self) -> Result<(Config, Option<ConfigPath>), anyhow::Error> {
let path = find_config_path(&self.config);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be shared between the forest and forest-cli. Imagine having a config file in the default location. If it is forest config file, forest-cli would fail on start. If it is a forest-cli config file, forest would die. In general, it'd be fantastic if those configurations, at least user-facing ones, would live in separate modules, not visible to each other.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no such thing as a forest-cli config, though, and there probably never will be.

Given that there is apparently no consensus about this, I think we should close this PR and move the discussion to an issue.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come there isn't? The CliOpts is the forest-cli config, it's what gets shown to the user via structopt, or am I missing something? If we don't want to have it and implement every flag at subcommand level, let's just get rid of this the CliOpts in this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Command-line options are different from a configuration file. In forest they are the same (which is a mistake, I believe, as it leads to some unintuitive behaviour). But for forest-cli there is no reason to have a configuration file.

Let's discuss in a separate issue.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with having no configuration file for forest-cli and removing this logic. What I am not okay with is having the same logic for the configuration file between forest and forest-cli.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not? We want the forest-cli tool to read the configuration file for the forest node, don't we?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean the same logic for loading two different files, including their default location. :)

Comment on lines +82 to +85
if let Some(metrics_address) = self.metrics_address {
cfg.client.metrics_address = metrics_address;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need a metrics server in the forest-cli?

Suggested change
if let Some(metrics_address) = self.metrics_address {
cfg.client.metrics_address = metrics_address;
}

Co-authored-by: Hubert <hubert@chainsafe.io>
@LesnyRumcajs
Copy link
Member

One other thing, DaemonOpts should not have the token field. As mentioned in the comment above it, it's for the client, i.e., forest-cli.

@lemmih lemmih closed this Nov 24, 2022
@LesnyRumcajs LesnyRumcajs deleted the jdjaustin/issue-2076-rm-incorrect-cli-usage-flags branch April 25, 2023 09:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants