A developer can pass data as part of an installation

[ghost]

The public spec supports an arg argument of type Blob during an install request. We need to support this in the CLI as well.

[nomeata]

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.

[luc-mercier]

Since dfx supports custom canisters, not just motoko, this is actually required.

[nomeata]

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 :-)

[crusso]

An external user (Norton Wang) also requested it here:

https://forum.dfinity.org/t/canister-installation-arguments/1254

[luc-mercier]

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 :)

[nomeata]

I wonder whether the 2 requests were somehow linked :)

No way!

[chenyan-dfinity]

#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:

• Ignore canisters that requires install arguments in install --all and deploy
• Have a field in dfx.json to specify the arguments

With 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?

[p-shahi]

part of this is done but the second half should be addressed with #1692