Closed ghost closed 3 years ago
Although need is a strong word. For now, Motoko doesn’t use this feature of the system, so one could argue that dfx
doesn’t have to support it either yet. Definitely not pressing.
Since dfx
supports custom
canisters, not just motoko, this is actually required.
Agreed. The same feature was requestd for hfx
a few days ago (https://github.com/dfinity-lab/dfinity/pull/5452), so there is demand now :-)
An external user (Norton Wang) also requested it here:
https://forum.dfinity.org/t/canister-installation-arguments/1254
Agreed. The same feature was requestd for
hfx
a few days ago (dfinity-lab/dfinity#5452), so there is demand now :-)
I wonder whether the 2 requests were somehow linked :)
I wonder whether the 2 requests were somehow linked :)
No way!
https://github.com/dfinity-lab/sdk/pull/1038 works for single canister install.
I want to discuss how to extend this to install --all
and deploy
. I can think of two options but none are perfect:
install --all
and deploy
dfx.json
to specify the argumentsWith this feature, we are starting to have one-to-many mapping from wasm module to canisters, e.g., I can create several counter canisters with different initial values:
dfx canister install counter '(0)'
dfx canister install counter '(1)'
dfx canister install counter '(2)'
And I should get three canister ids associated with the counter
module. How does dfx manage this mapping?
For my PR, I will just handle the single canister install with only one canister id case, and let the team decide how to support the more general case. WDYT?
part of this is done but the second half should be addressed with https://github.com/dfinity/sdk/issues/1692
The public spec supports an
arg
argument of type Blob during aninstall
request. We need to support this in the CLI as well.