Rust bindgen possibility for PocketIC

[edwardoranj]

It would be great if we have PocketIC value in this enum to generate PocketIC compatible client.

cdk-rs/src/ic-cdk-bindgen/src/code_generator.rs

Lines 9 to 13 in 929fd0b

	pub enum Target {
	CanisterCall,
	Agent,
	CanisterStub,
	}

[lwshang]

Let me start with some clarification on what is ic-cdk-bindgen.

The code you linked above was mostly copied and simplified from https://github.com/dfinity/candid/blob/master/rust/candid_parser/src/bindings/rust.rs

And there is some unfinished experiment on the next generation of ic-cdk-bindgen in bindgen_next branch: https://github.com/dfinity/cdk-rs/tree/bindgen_next/src/ic-cdk-bindgen

There was a debate on where should such bindgen tool live.
My opinion is that, the bindgen tool should live in the same place as where it is used.
ic-cdk-bindgen should only be in responsible for generating the bindings for Rust CDK usage (not Rust Agent or something else).
Keeping ic-cdk and ic-cdk-bindgen in the same codebase is the only way to guarantee that they work together.
That's the reason of moving the CanisterCall bindgen from the candid repository to this cdk-rs repository.

---

Then let's talk about PocketIC bindgen.

What kind of code do you want to generate?

PocketIC is mostly used for test canisters end-to-end. Do you want to generate some testing code for you canisters?
Because the generated code will be deeply coupled with the PocketIC API, it's better to have the bindgen logic next to the PocketIC code.

Then it is out of the scope of this repository.

---

In the bindgen_next branch, I changed the Target definition to:

cdk-rs/src/ic-cdk-bindgen/src/lib.rs

Lines 82 to 87 in e78726a

	#[derive(Clone, Copy, Debug, PartialEq, Eq)]
	enum Target {
	Consumer,
	Provider,
	Type,
	}

So you can generate bindings containing the Rust types only. The types would already be useful for testing.

[edwardoranj]

Hi @lwshang,

Thank you for sharing your thoughts. I will test your updates on the bindgen_next branch. I believe this is the best place to discuss this, as ic-cdk-bindgen generates Rust types from the DID file. Regarding PocketIC, as you know, it is used to test canisters end-to-end, and we need to have a Rust client for the canister in the PocketIC environment. I believe this can be generated from the bindgen, as it already has the capability to generate Rust types.

While I agree with you about the location of the code, generating such canister clients in PocketIC using ic-cdk-bindgen will save a lot of time on writing integration tests. These are my honest thoughts.

I hope there will be active discussion on this topic, thanks!