Initial setup #1
Conversation
rust-toolchain
Outdated
| @@ -0,0 +1 @@ | |||
| nightly-2022-11-28 | |||
There was a problem hiding this comment.
needed? or else too opinionated?
There was a problem hiding this comment.
I'd avoid nightly personally if at all possible (but perhaps it's not in this case; I haven't dug into the code yet). Assuming it's needed, I think pinning to a specific one is a good approach to avoid random breakages and such (like any version it should periodically be updated though, so perhaps a more recent one is possible?)
|
Would love to have a look a this soon! thanks for the initiative :) |
|
Should we make this a workspace? |
|
related: paritytech/substrate#12975 |
| use subxt::PolkadotConfig; | ||
| use try_runtime_core::commands::TryRuntime; | ||
|
|
||
| #[subxt::subxt( |
There was a problem hiding this comment.
any thoughts about how this would work against arbitrary substrate-based chains? I am sure I was told subxt supports this, but don't have it off the top of my head.
There was a problem hiding this comment.
This macro generates all of the static interface to talk to the node that the metadata comes from. Currently, as long as other nodes support the exact same interface that the metadata was generated against, it'll mostly Just Work. Subxt will take care of things like call indexes and pallet indexes being different across nodes.
subxt has validation logic which will do a runtime check when you use this interface to verify that the calls etc you use line up with the node you're trying to talk to (this validation can be switched off if you want to yolo it)
An in flight PR moves the static interface to use new encode and decode machinery (see scale-encode and scale-decode crates) which loosens the requirements on the static code the macro generates being exactly identical to the metadata, basically giving more leeway for things to keep working if the interface does change a little in certain ways (though the validation logic still will warn if things change and needs opting out of if interfaces do change in a breaking way)
So yup, it'll work cross chain as long as the pallet interfaces you use line up.
There was a problem hiding this comment.
I will make it more universal with build.rs module that will allow for custom node address for scraping runtime configuration. In a next PR :)
There was a problem hiding this comment.
Great to have a kickstart here. Happy to iterate fast, and bring over more functionality. Once feature-complete, we should delete this from substrate.
@paritytech/tools-team/@jsdw would you help with the ownership of this line of work? it is sub-xt user, and if the plans we have with @pmikolajczyk41 work out, it will be a single tool that can be used across the entire ecosystem.
| use try_runtime_core::commands::TryRuntime; | ||
|
|
||
| #[subxt::subxt( | ||
| runtime_metadata_url = "wss://rpc.polkadot.io:443", |
There was a problem hiding this comment.
I'd recommend bundling the metadata with the tool, so that:
- Compiling this code doesn't require network access to download the metadata
- Changes to the metadata don't lead to this suddenly being unable to compile (it's good to be aware of such changes though, but for that a CI step can be used; eg we could put a version of this macro that calls the URl behyind a feature flag to make it easy to run a daily check that the code compiles against latest still)
There was a problem hiding this comment.
Thanks for the suggestions. I will take care of CI pipelines later on. Combining this comment with the other, I think the best solution will be to have:
- generated polkadot runtime file for default, offline compilation
build.rsmodule for customizing runtime (however it will require network access or a custom file)
cli/main.rs
Outdated
|
|
||
| type UncheckedExtrinsic = generic::UncheckedExtrinsic< | ||
| <PolkadotConfig as subxt::Config>::Address, | ||
| polkadot::runtime_types::polkadot_runtime::RuntimeCall, |
There was a problem hiding this comment.
Will this RuntimeCall enum expect to be scale encoded (via .encode()) to send valid transactions to a node? If so, note that it will not be portable across runtimes, as the pallet indexes etc are very likely to be different in different runtimes.
(Subxt doesn't use this enum directly in its APIs and manually lines up indexes when encoding calls, and the new scale-encode (and updated scale-decode) crates help to encode things based on metadata (which in the case of variants means they will be lined up by name, not declaration order). Maybe these can help in some way, but I'm not sure how it's used yet :))
There was a problem hiding this comment.
as discussed off-GH, currently, RuntimeCall is needed for building correct Block type, which will then be needed for just processing blocks and transactions within externalities, so we should be ok with this code
This PR introduces:
try-runtime-corelibrary cratetry-runtime-clibinary cratetry-runtime-corelibrary crateWe expose a library that gathers all available try-runtime actions. They can be used either directly in some CLI tool or composed into another library. There is a feature
"cli", which exports someclap-based command structs that can be conveniently injected to other (broader) tools or used as standalone tools.try-runtime-clibinary crateWe expose a simple CLI tool that is suited for Polkadot.
Notes
on-runtime-upgradeorfollow-chain) and chain-specific (likefast-forward). Therefore, we must enable end-users for easy and flexible tool composition - this is why we expose actions both as plain functions and as granular commands.on_runtime_upgradewas migrated, so that reviewing / editing is easier and faster. The rest of commands will be migrated after this PR is merged.subxtis now set for1c5faf3- the latest release doesn't work with recent Substrate libraries. It should be set to0.27.2once it is released.sc_cli::Result, probablytry-runtime-specific error enum - to be done.