Extending DFX to support WASI

Developers
1

Hello, I would like to propose extending DFX to support WASI. With WASI you can use the standard Rust functions to work with files, access time, randomness, and output messages into DFX console using println! macro. (No support for sockets.)

I have created an MVP: GitHub - wasm-forge/sdk: IC SDK: a Software Development Kit for creating and managing canister smart contracts on the ICP blockchain. , it integrates the wasi2ic converter and automatically prepares a WASI binary to be launched in the IC environment. You can clone it and compile the custom dfx:

export DFX_VERSION=0.29.0
cargo build

The dfxcommand now contains a new Rust (WASI) workflow, it creates a basic “Hello World“ example with some file operations. With it you can start building Rust WASI canisters and integrate existing WASI projects (something that compiles to the wasm32-wasip1 target), see some examples here: GitHub - wasm-forge/examples: Examples of running WASI applications on the Internet Computer .

When your “hello world“ sample is created by dfx, enter the project folder and run dfx deploy.

3 Likes
2

I’m not sure that wasi2ic support is the best fit for direct dfx support. wasi2ic is a community-developed workaround based on the (now discontinued) first preview of WASI; the ideal official dfx WASI support would be to a first approximation stabilized around the official release of WASI (and if possible, be based around linking support instead of postprocessing). This instead looks like it would be a good fit for a dfx extension, similar to Azle, where a third-party module can be used to build canisters in a more streamlined way than type:custom. The docs on how to do this are basically nonexistent right now but some examples can be extracted from our unit tests and Azle has a practical instance of one.

2 Likes
3

Basically you’re saying that WASI support should be incorporated into dfx natively eventually, but not based on the outdated wasi-preview-1?

I suppose that makes sense. We’re very excited to get Azle off of wasi2ic without post-processing of the Wasm binary. We’re also very excited to have a WASI implementation in dfx that is fully supported and reviewed by DFINITY. But waiting for the official release of WASI makes sense…except for how long that will take.

1 Like
4

Hi @sgaflv, thanks for putting effort into this.

For now, like @AdamS says, it makes more sense to add this into dfx as an extension.

You can checkout these repos for examples:
(1) https://github.com/rikonor/dfx-extension
(2) https://github.com/rikonor/dfx-extension-ping
(3) https://github.com/rikonor/dfx-extensions

Also, the tests may be helpful in some cases: https://github.com/dfinity/sdk/blob/master/e2e/tests-dfx/extension.bash

Around mid September, we’re also aiming to make a preview release of the new icp-cli - I think it will make it even easier for you to extend that with a build template. Stay tuned.

5

Same thing for you @lastmjs - I’d be happy to get your feedback on the icp-cli in a couple of weeks, specifically how it would allow you to create build and deployment templates for azle.

1 Like
6

Yes, I think it makes more sense as an extension.
Thank you very much for the information, I will look into it.

2 Likes