Open bkchr opened 6 days ago
From the linked issue, I like the idea that you can point Subxt at the WASM runtime and have it extract and use the metadata from it. Then, I think we could have:
runtime_metadata_path
- get metadata from pathruntime_metadata_insecure_url
- get metadata from (possibly not secure) URLruntime_path
- get metadata from runtime at pathI'd prefer to avoid the subxt macro having to know or care anything about the structure of the polkadot-sdk
repo if possible :)
I'd prefer to avoid the subxt macro having to know or care anything about the structure of the
polkadot-sdk
repo if possible :)
I mean what I proposed does not require to know the structure of the repo? Only need to know how substrate-wasm-builder
works, but this is reasonable.
The
subxt
macro currently supports to fetch the metadata from the filesystem or from some RPC node. However, for the future zombienet rust tests, it would be nice to also specify a crate.So, something like this:
The
crate_name
would be required to be path of the same workspace.wasm_file_name
should be optional and if not given, it should be guessed based on the build output. If there is more than one wasm file, the macro should complain.features
is also optional and just activates some feature at compile time.https://github.com/paritytech/polkadot-sdk/tree/85f0edae1d6c461081f42fcabd13e547e5a5b683/substrate/.maintain/build-only-wasm.sh could be helpful here.