try-runtime-cli: path to being an independent CLI

[kianenigma]

... and capable of interacting with any substrate-based chain, at any without needing to care about the block format.

As of #12537, the try-runtime-cli does not care about the local runtime anymore. It always uses the path to the wasm file.

If you look at the code now, there are only two reasons why try-runtime-cli is part of substrate/polkadot/cumulus now:

1. Get the list of host functions from the native executor
2. Get the block format

substrate/bin/node/cli/src/command.rs

Lines 241 to 244 in e118df5

	cmd.run::<Block, ExtendedHostFunctions<
	sp_io::SubstrateHostFunctions,
	<ExecutorDispatch as NativeExecutionDispatch>::ExtendHostFunctions,
	>>(),

The former can be hardcoded and as far as I know we don't really change it. It should simple be SubstrateHostFunctions default set.

And the latter, should be provided by sub-xt. sub-xt is now capable of fetching the metadata of a remote node and generating types from it, including the block format, at compile-time, which is awesome and exactly what we need.

If done, there'd be one try-runtime-cli, capable of working with all substrate-based chains, with much faster compile-time, and capable of living outside of substrate repo even.

Tasks

Beta Give feedback

1. Standalone repo and docs v0.1.0: ready to replace existing substrate subcommand try-runtime-cli#6
2. Link docs on https://paritytech.github.io/ https://github.com/paritytech/paritytech.github.io/pull/12
3. Deprecate node-cli try-runtime subcommand deprecate try-runtime subcommand and direct users to standalone cli #14731
4. Migrate try-runtime issues to new repo
5. Update substrate.io docs to point to standalone cli docs Update try-runtime.md polkadot-developers/substrate-docs#2043

[pmikolajczyk41]

Generally, extracting try-runtime outside node binary sounds great for me. However, there is at least one thing that I want to bring some attention to.

Since we have the assumption that try-runtime is a universal tool (in terms of chain it communicates with), in some future situations we might have to allow users to inject custom logic. As an example, you can refer to my PR with fast-forward subcommand. There, I require from the user to provide a 'factory' of inherents and pre-runtime digests. Similar thing will occur if we decide to add block translation gadget (for block format mismatch) - the user will have to define logic for how old extrinsics should be translated to the new ones.

For such cases, I would propose dividing try-runtime into lib and bin crates, where the latter one would be ready-to-use CLI tool, that exposes all the functionalities that don't require external logic. The former would keep all the non-CLI code, including additional generic functionalities (for injecting custom semantics) - like fast-forward.

[kianenigma]

For such cases, I would propose dividing try-runtime into lib and bin crates, where the latter one would be ready-to-use CLI tool, that exposes all the functionalities that don't require external logic.

Perhaps the lib-part can go into frame/try-runtime which already exists?

[pmikolajczyk41]

where would we keep the binary (the tool)? other repository?

[kianenigma]

I would start with this repo but no dependency on sc-*, and then it would be free to go anywhere

[pmikolajczyk41]

Sounds good then

[kianenigma]

https://github.com/paritytech/try-runtime-cli is there for me and @pmikolajczyk41 to try this out.