Dev Blog: Introducing `dfx deploy --playground`

Developers Education
, ,
1

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.

You can read more in the blog post here.

9 Likes
2

As a point of clarity from the release notes at https://github.com/dfinity/sdk/releases/tag/0.15.1:

import management "ic:aaaaa-aa;

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?

3

@ericswanson Could you provide some insight for this?

4

According to the PR that introduced the feature,

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.

5 Likes
5

Hey it would be great for the playground to work with gzipped binaries and the upcoming dfx binary upload chunking.

Azle and Kybra canisters are simply not able to use the playground because of this.

2 Likes
6

Pretty simple to use… thank you.

7

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!

1 Like
8

Does the chunk upload interface work now?

9

No, it still even struggles with 2MB payloads

1 Like
10

Canisters deployed on the playground are only available for 20 minutes. But what if there’s a case in which I have to constantly instantiate new data every time I create my canister? That means after every 20 minutes I’d have to create a new set of data every time I deploy my canister, which might be very inconvenient and not provide a good developer experience.

Is there a scenario where I can make my canister available for more than 20 minutes :thinking:?

Like every time I do dfx deploy --playground it would revise the timer and my 20 minutes would start counting again. Is it possible?

11

That already happens. If you redeploy the timer gets reset.

1 Like