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

Support fetching metadata from crate #1660

Open
bkchr opened this issue Jun 27, 2024 · 2 comments
Open

Support fetching metadata from crate #1660

bkchr opened this issue Jun 27, 2024 · 2 comments

Comments

@bkchr
Copy link
Member

bkchr commented Jun 27, 2024

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:

subxt(runtime_crate = "crate_name", wasm_file_name = "name", features = ["fast-runtime"])

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.

@jsdw
Copy link
Collaborator

jsdw commented Jun 27, 2024

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 path
  • runtime_metadata_insecure_url - get metadata from (possibly not secure) URL
  • runtime_path - get metadata from runtime at path

I'd prefer to avoid the subxt macro having to know or care anything about the structure of the polkadot-sdk repo if possible :)

@bkchr
Copy link
Member Author

bkchr commented Jun 28, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants