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

Introduce CLI command #5

Merged
merged 4 commits into from
Sep 29, 2023
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
clap = "4.4.0"
ethers = "2.0.10"
eyre = "0.6.8"
serde_json = "1.0.107"
Expand Down
58 changes: 58 additions & 0 deletions src/main.rs
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I choose the builder style since I don't anticipate that many sub-commands or arguments and they are pretty self-descriptive this way.

Copy link
Member

Choose a reason for hiding this comment

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

Gotcha, to be honest I'm not a huge fan of the builder style in general since I think it's a lot harder to understand how everything relates even when we don't have a lot of commands. However, if it's what you prefer I'm fine with it - I know that I'll be integrating database source arguments, but other than that I can't imagine many more arguments/sub-commands for now.

Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
use clap::{arg, value_parser, Command};

fn cli() -> Command {
Command::new("state-reconstruct")
.about("zkSync state reconstruction tool")
.subcommand_required(true)
.arg_required_else_help(false)
.subcommand(
Command::new("import")
.about("Import state")
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
Command::new("import")
.about("Import state")
Command::new("reconstruct")
.about("reconstruct state")

Nit: maybe "reconstruct" since we are doing a lot more than just importing the L1 state.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Initially my thinking was that there would be export as well and in that case, I don't think deconstruct is necessarily that sound expression for the behaviour 😄

...but, revisiting requirements, I think officially there won't be export functionality so I'm ok with this. I'm thinking of hidden export command though, because we do need it for development purposes.

.subcommand_required(true)
.subcommand(
Command::new("l1")
.about("Import state from Ethereum L1")
.arg(
arg!(--"start-block" <START_BLOCK>)
.help("Ethereum block number to start state import from")
.default_value("16627460")
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
.default_value("16627460")
.default_value(ZKSYNC_GENESIS_BLOCK)

The default value should be a constant.

.value_parser(value_parser!(u64)),
)
.arg(
arg!(--"block-step" <BLOCK_STEP>)
.help("Number of blocks to filter & process in one step")
.default_value("128")
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
.default_value("128")
.default_value(DEFAULT_BLOCK_STEP)

.value_parser(value_parser!(u64)),
),
)
.subcommand(
Command::new("file")
.about("Import state from file")
.arg(arg!(<FILE> "File to import state from"))
.arg_required_else_help(true),
),
)
}

fn main() {
let matches = cli().get_matches();

match matches.subcommand() {
Some(("import", sub_matches)) => {
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
Some(("import", sub_matches)) => {
Some((Command::Reconstruct, sub_matches)) => {

Do you know if there's any way to have the commands and sub-commands as Enums, like we can with the #[derive(Parser)] method? Would make it easier to maintain in the future.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I briefly looked at this while writing the code. You can create an enum and workaround it here, but I personally would lean towards not having that boilerplate since I don't think these few string occurrences can cause any issues here.

match sub_matches.subcommand() {
Some(("l1", args)) => {
let start_block = args.get_one::<u64>("start-block").expect("required");
let block_step = args.get_one::<u64>("block-step").expect("required");
println!("import from L1, starting from block number {}, processing {} blocks at a time", start_block, block_step);
// TODO(tuommaki): Implement block fetch logic.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'll build this in small steps 🙂

}
Some(("file", args)) => {
let input_file = args.get_one::<String>("FILE").expect("required");
println!("import from file (path: \"{}\")", input_file);
}
_ => unreachable!(),
}
}
_ => unreachable!(),
}
}