Automatically generate candid from rust sources

I had the issue that the candid was no longer available on icscan.io and the Candid UI.

I solved it by adding this to my canister code (taken from here).

/// This makes this Candid service self-describing, so that for example Candid UI, but also other
/// tools, can seamlessly integrate with it. The concrete interface (method name etc.) is
/// provisional, but works.
#[query]
fn __get_candid_interface_tmp_hack() -> String {
    include_str!("<my_canister_name>.did").to_string()
}

I had the understanding the export_candid!() from the guide covered this. Is that not the case?

The “export Candid” workflow in Rust CDK has been changed since the guide you were referring.

This page describes the steps in ic-cdk v0.11.

Yes, I have ic_cdk with v0.11.0 but I still needed to add the __get_candid_interface_tmp_hack() for candid UI and icscan to be able to extract the candid.

I guess this shouldn’t be the case and adding at ic_cdk::export_candid!(); to my code should cover that normally?

Thanx @peterparker and @lwshang,

I also saw in the discord thread.
Finally some good news,
Cant wait to test it out.
Gonna take a few more days until I circle back.

I will report back how it goes.

1 Like

If you get the candid file correctly by running this.

Step 3: Extract candid from the Wasm module and save to a file:

candid-extractor target/wasm32-unknown-unknown/release/<CANISTER>.wasm > <CANISTER>.did

You already have the candid implementation on your wasm, it will generate a candid file from your WASM file!

Why do we need a separate binary to be installed?

Why not put this in dfx itself and let it be done as part of dfx build, dfx generate or dfx deploy for project types of rust in the dfx.json file?

1 Like

Because you don’t necessary need dfx to build canisters I would say.

That said, I understand that the DX will improve over time, and this was a good initial step and it will ultimatelly be integrated in dfx as well. Again if I understand correctly.

I kinda disagree. I would argue that almost all canister developers use dfx to build their canisters.

And it’s a good idea to co-locate all functionality related to canister building into dfx instead of maintaining different tooling for related tasks

I don’t build Juno with dfx, nor do we build Internet Identity with it :wink:.

(Not that I unfluenced the design in any ways, not part of that team)

I also guess it was first useful to build the feature as a standalone before integrating it within the dfx kitchen sink.

Anyways, like I said, the ultimate plan I understand is to improve the DX and also integrate it with DFX commands.

1 Like