With the latest release of dfx 0.15.1, we’re excited to announce a new dfx subcommand: dfx deploy --playground!
--playground (or --network playground) is a new network flag for the dfx deploy command that deploys the project’s canister(s) to the Motoko playground’s canister pool instead of deploying them to the local replica (--network local) or the mainnet network (--network ic).
When this flag is used, the canisters are deployed in a manner where they borrow resources from the Motoko playground’s canister pool. The Motoko playground provides developers with an environment where canisters can be deployed and tested quickly without needing to configure a cycles wallet.
Does this work for all canisters or just the management canister? Does it use the ‘pullable’ interface, or just rely on a candid interface being deployed at the hidden idl endpoint?
The execution team is planning on adding the idl to the replica, but until then it can be hard coded in dfx and swapped out later on.
This works only for the management canister.
It doesn’t use the pullable interface, or any other candid interface or hidden idl endpoint. Instead, dfx has hardcoded a version of the management canister’s idl.
After the replica supports a way to query the management canister’s idl, we’ll update dfx to use that instead.
Having this apply to any canister that supports the pullable interface, just by putting in an import statement, is an interesting idea and something that we have talked about. Conceptually these seem similar to each other:
dfx.json defines canister N as pullable from principal P
import N "ic:P"
So we’ve talked about the second form being another way of defining a pulled canister for the project. The management canister is a special case in that dfx never needs to install it locally. So another question is whether the second form would be another way of declaring a pulled canister, or only pull the candid interface.
I wish we had a way to do gzipped binaries. The playground strips out forbidden methods (think draining the playground’s cycles). If we unzip and zip it back up we run into execution limits very quickly. If anyone has good ideas how to do it I’d be very happy to hear ideas!