Repository: paritytech/substrate
File: utils/frame/try-runtime/cli/src/lib.rs (Rust)

Code before:
//!     snap -s node-268@latest.snap
//! ```
//!
//! * Execute the latest finalized block with the given runtime.
//!
//! ```bash
//! ./substrate-try-runtime try-runtime \
//!     --runtime runtime-try-runtime.wasm \
//!     -lruntime=debug \
//!     execute-block live \
//!     --uri ws://localhost:9999
//! ```
//!
//! This can still be customized at a given block with `--at`. If you want to use a snapshot, you
//! can still use `--block-ws-uri` to provide a node form which the block data can be fetched.
//!
//! Moreover, this runs the `frame_support::try_runtime::TryState` hooks as well. The hooks to run
//! can be customized with the `--try-state`. For example:
//!
//! ```bash
//! ./substrate-try-runtime try-runtime \
//!     --runtime runtime-try-runtime.wasm \
//!     -lruntime=debug \
//!     execute-block live \
//!     --try-state System,Staking \
//! 		--pallet System,Staking \
//!     --uri ws://localhost:9999
//! ```
//!
//! Will only run the `try-state` of the two given pallets. When running `try-state` against
//! some real chain data it can take a long time for the command to execute since it has to
//! query all the key-value pairs. In scenarios like above where we only want to run the
//! `try-state` for some specific pallets, we can use the `--pallet` option to specify from
//! which pallets we want to query the state. This will greatly decrease the execution time.
//!
//! See [`frame_try_runtime::TryStateSelect`] for more information.
//!
//! * Follow our live chain's blocks using `follow-chain`, whilst running the try-state of 3 pallets
//!   in a round robin fashion
//!
//! ```bash
//! ./substrate-try-runtime \
//!     try-runtime \
//!     --runtime runtime-try-runtime.wasm \
//!     -lruntime=debug \
//!     follow-chain \
//!     --uri ws://localhost:9999 \
//!     --try-state rr-3
//! ```

#![cfg(feature = "try-runtime")]

Review comment (suggestion):
```suggestion
//! 	--pallet System,Staking \
```

Code after:
//!
//! This can still be customized at a given block with `--at`. If you want to use a snapshot, you
//! can still use `--block-ws-uri` to provide a node form which the block data can be fetched.
//!
//! Moreover, this runs the `frame_support::try_runtime::TryState` hooks as well. The hooks to run
//! can be customized with the `--try-state`. For example:
//!
//! ```bash
//! ./substrate-try-runtime try-runtime \
//!    --runtime runtime-try-runtime.wasm \
//!    -lruntime=debug \
//!    execute-block \
//!    --try-state System,Staking \
//!    live \
//!    --uri ws://localhost:9999 \
//!    --pallet System Staking
//! ```
//!
//! Will only run the `try-state` of the two given pallets. When running `try-state` against
//! some real chain data it can take a long time for the command to execute since it has to
//! query all the key-value pairs. In scenarios like above where we only want to run the
//! `try-state` for some specific pallets, we can use the `--pallet` option to specify from
//! which pallets we want to query the state. This will greatly decrease the execution time.
//!
//! See [`frame_try_runtime::TryStateSelect`] for more information.
//!
//! * Follow our live chain's blocks using `follow-chain`, whilst running the try-state of 3 pallets
//!   in a round robin fashion
//!
//! ```bash
//! ./substrate-try-runtime \
//!     try-runtime \
//!     --runtime runtime-try-runtime.wasm \
//!     -lruntime=debug \
//!     follow-chain \
//!     --uri ws://localhost:9999 \
//!     --try-state rr-3
//! ```

#![cfg(feature = "try-runtime")]

use crate::block_building_info::BlockBuildingInfoProvider;
use parity_scale_codec::Decode;
use remote_externalities::{
	Builder, Mode, OfflineConfig, OnlineConfig, RemoteExternalities, SnapshotConfig,
	TestExternalities,
};
use sc_cli::{
	execution_method_from_cli, CliConfiguration, RuntimeVersion, WasmExecutionMethod,
	WasmtimeInstantiationStrategy, DEFAULT_WASMTIME_INSTANTIATION_STRATEGY,
	DEFAULT_WASM_EXECUTION_METHOD,