cdk-rs
cdk-rs copied to clipboard
dfinity
API function for canister creation
Can we please get a function in the Rust CDK for canister creation and installation. https://docs.dfinity.systems/public/#ic-create_canister
The replica used in DFX already supports this functionality, we only need some interface functions
The management canister is (well, looks like) any other canister, so you probably don’t need special support in the CDK – just call it like you would call your cousin’s amazing chat canister.
Do-it-yourself is certainly an option @nomeata. However, I wouldn't expect all IC users to manually craft and send messages to IC00 or aaaa-a. Maybe at some point we decide that IC00 should be renamed, or should get different arguments, or even that the same function will be performed by an entity in the replica other than the management canister.
Therefore, it would be useful and beneficial to all of us to have a layer of abstraction between the IC implementation and the API that the users would use. In my view, that is the purpose of the SDK/CDK.
Maybe at some point we decide that IC00 should be renamed,
That point came sooner than hoped for: https://github.com/dfinity-lab/ic-ref/pull/151 :-/
Therefore, it would be useful and beneficial to all of us to have a layer of abstraction between the IC implementation and the API that the users would use. In my view, that is the purpose of the SDK/CDK.
Oh, for the SDK, absolutely, yes. For the CDK (in the narrow sense of “rust libraries to create canisters”, and not the broader sense that includes tools to upload canisters like dfx) I don’t think it is absolutely needed. But if convenient, not opposed – just pointing out that nobody ought to have to wait for this to happen, as you can use aaaaa-aa directly (as opposed to, say, new system api calls, which are typically not directly usable without changing the CDK)
Just a comment that I've already implemented this for BigMap, but would appreciate if someone (@hansl?) takes this code into the CDK. PTAL: https://github.com/dfinity/bigmap-rs/blob/9ade1529d6a1816ae56c52c9167c520f72f303f8/src/canister_management.rs#L10
There are some replica internals that the caller needs to know in order to craft an appropriate message for canister creation and code install.
There are some replica internals that the caller needs to know in order to craft an appropriate message for canister creation and code install.
Replica-internals, as in stuff not documentd in the Public Spec? What would they be?
Replica-internals, as in stuff not documentd in the Public Spec? What would they be?
As in: it's mandatory to provide a struct called exactly InstallCodeArgs with fields called exactly this and that. Changes in the fields of this struct become increasingly difficult if canisters depend directly on them.
Similar thing for https://github.com/dfinity/bigmap-rs/blob/9ade1529d6a1816ae56c52c9167c520f72f303f8/src/canister_management.rs#L5 (CanisterIdRecord). Canister creation doesn't work if the struct is named something else.
I don’t believe the name of the struct matters. The field names are part of the Candid interface, but that is documented in the public spec: https://docs.dfinity.systems/public/v/0.10.2/#ic-candid
If “There are some replica internals that the caller needs to know” the something is seriously broken.
I don’t believe the name of the struct matters. The field names are part of the Candid interface
Looks like you're right. The names of the structs don't matter, but the names of the fields do matter and the operations fail if the fields are named in any other way. For example:
[Canister 75hes-oqbaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q] Panicked at 'Failed to deserialize 4449444c016c01b3c4b1f2046801000112050000000000000000000000000000000001 = Ok(IDLArgs { args: [Record([IDLField { id: Id(1313628723), val: Principal(Principal(OpaqueId([5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]))) }])] }) to 1 argument; Decode error: Deserialize error: Deserialize error: missing field `canister_id_x`', /home/sat/projects/bigmap-rs/vendor/rust-cdk/src/ic_cdk/src/api/context.rs:137:17
We don't have to do anything for this issue, I'm not passionate about it. I do believe it improves the DX and that's why I created, but you seem to feel that it doesn't, or that it's better if developers do all this. I don't mind, really. Developers will search for the snippet which does the job, find it in the end, and copy&paste it into their app. It just won't be pleasant.
I'll stop here and let @hansl decide what to do.
the names of the fields do matter and the operations fail if the fields are named in any other way.
Yeah, field names are part of the interface…
I am not opposed to providing a convenience function in the rust CDK, I was merely pointing out that it is not strictly necessary.
Replica-internals, as in stuff not documentd in the Public Spec? What would they be?
As in: it's mandatory to provide a struct called exactly
InstallCodeArgswith fields called exactly this and that. Changes in the fields of this struct become increasingly difficult if canisters depend directly on them.Similar thing for https://github.com/dfinity/bigmap-rs/blob/9ade1529d6a1816ae56c52c9167c520f72f303f8/src/canister_management.rs#L5 (
CanisterIdRecord). Canister creation doesn't work if the struct is named something else.
The github link is broken
The github link is broken
It's not, bigmap-rs is currently private. For reference, the structure referred to looks like this:
#[derive(CandidType, serde::Deserialize, Debug)]
struct CanisterIdRecord {
canister_id: candid::Principal,
}