Add cli to template #68
Conversation
| let keypair = <sr25519::Pair as Pair>::from_string(&mnemonic, None).unwrap(); | ||
| println!("Uploading program using account: {}", keypair.public()); | ||
|
|
||
| let program = include_bytes!("../../target/wasm32-unknown-unknown/release/{{project-name}}.wasm").to_vec(); |
There was a problem hiding this comment.
This means we must run the CLI from the project root. Which is probably fine. But there is a crate https://docs.rs/project-root which finds the project root by searching for the nearest Cargo.lock file.
There was a problem hiding this comment.
Potentially we could run cargo component build before doing this, to be sure the binary is up to date.
There was a problem hiding this comment.
ahhh yes I like both these ideas
|
|
||
| let program = include_bytes!("../../target/wasm32-unknown-unknown/release/{{project-name}}.wasm").to_vec(); | ||
| let config_interface = fs::read("{{project-name}}_serialized_config_type.txt")?; | ||
| let aux_data_interface = fs::read("{{project-name}}_serialized_aux_data_type.txt")?; |
There was a problem hiding this comment.
I guess if these don't exist we could run generate-types here. Or combine this and the generate-types crate into one crate
| } | ||
| } | ||
|
|
||
| pub async fn store_program( |
There was a problem hiding this comment.
If we add entropy-testing-utils as a dependency, i think all of the code below is already available, which would make maintaining this crate much easier. Also the chain metadata, which is otherwise going to be annoying to have to update here whenever it changes.
The downside is that entropy-testing-utils has entropy-tss as a dependency, which makes it pretty bloated. Ideally i would like to refactor the few bits which testing-utils depends on into a shared crate. And maybe separate the test client from the rest of testing-utils, which i have been hesitant about doing, because it basically means we have a rust SDK, which might be treading on some toes.
There was a problem hiding this comment.
also the metadata too, having a rust sdk is def not treading on toes so no worries there. I was thinking this but as it is closed sourced and others need to pull this in I was like eh copy and paste it to get moving and fix it later
There was a problem hiding this comment.
Generally this looks great. I think it would be nice if this was a generic binary rather than needing to be compiled for every project. As in this crate should live outside of the cargo-generate template, and be installed just once with cargo install.
In the long term, i would like it if this tool would have an option to specify whether the program is intended to be publicly available, and if it is, then make an HTTP request to the program-metadata-web-service, which pulls the name and description etc, from Cargo.toml and makes that data available through a json http api. The testnet status page uses it to display names in the list of programs. And the SDK could use it to make a 'program picker' for users.
But the program-metadata-web-service is not yet deployed. And it requires you to build the program with docker in order that it can verify that the source code matches the on-chain binary.
I like your vision here, imma take some of your suggestions, but would really like if you could make some issues with the ideas cuz most of them are fire |
Adds a cli tool to the template to upload programs
This can get better when we open source core, the CLI should probably pulled in from core when we do that, but until then this should get the ball moving.