A Rust CLI for mops

[chenyan-dfinity]

Hi, great work on mops!

I'm writing a Rust implementation of the mops CLI: https://github.com/chenyan2002/mops-cli

The main focus at the moment is mops build. There are some different design choices, which I documented in the README. It's perfectly fine for the node CLI to stay as it is, but I'm happy to discuss if some of the changes can be ported here for better DX.

I consider this Rust CLI as a contribution to the mops ecosystem. It's in no way to replace the node CLI. I'm also planning to add mops in Motoko playground, so there will be another client soon :)

[ZenVoich]

Hi, @chenyan-dfinity !

I wonder what the use case for mops build command?
Looks like an alternative to dfx build with canisters listed in mops.toml as in dfx.json

I'm also planning to add mops in Motoko playground, so there will be another client soon :)

Nice 👍 Perhaps this will be helpful - #165 (comment)

[chenyan-dfinity]

Some motivations for this project:

• We are trying to reduce the amount of work to build a Motoko canister. With dfx build, you always need to provide dfx.json, and perhaps mops.toml. And you need to get a canister id before you can build. With the new mops build, you can get started with just main.mo. In most cases, mops.toml can be auto-generated, even moc can be downloaded automatically.
• This also separates out the moc release from dfx release. When there is a new moc release, users don't need to wait for the dfx release.
• We also want to simplify the dfx build command. With the this mops cli, dfx build will simply call mops build for Motoko canisters, and cargo build for Rust canisters.
• During this development, we noticed that version resolving in mops is not great. Even our base library is not following semantic versioning. And we need compiler support to allow compiling different versions of the same package in a project.
• Another minor point is that we want to have a build tool without the node runtime. Requiring npm to build Motoko canisters is another barrier for some developers.

[ZenVoich]

• This also separates out the moc release from dfx release. When there is a new moc release, users don't need to wait for the dfx release.

BTW it is possible to choose moc version with mops https://docs.mops.one/cli/toolchain

• We also want to simplify the dfx build command. With the this mops cli, dfx build will simply call mops build for Motoko canisters, and cargo build for Rust canisters.

Interesting. Does Rust CDK allow to define the canister ids somewhere else than dfx.json? What if to use dfx.json (with specified_id) to store canister name/ids?

• During this development, we noticed that version resolving in mops is not great. Even our base library is not following semantic versioning. And we need compiler support to allow compiling different versions of the same package in a project.

Agree. Linking my 1y old issue in motoko repo dfinity/motoko#3971

The latest update to Mops introduced a dependency version pinning feature. So now it is possible to have 2 or more version of the same package in a project.

[chenyan-dfinity]

BTW it is possible to choose moc version with mops https://docs.mops.one/cli/toolchain

Yeah, I should do that. Not implemented yet. One question is how strict we should follow the toolchain version. A library may be written years ago and pinned to an old release. But it may run just fine with the latest moc.

Interesting. Does Rust CDK allow to define the canister ids somewhere else than dfx.json? What if to use dfx.json (with specified_id) to store canister name/ids?

The [[canister]] section in mops.toml only refers to the imported canisters. I think it's different from what dfx.json specifies. There is also an internal discussion about how we can refactor dfx.json. The main problem is that build and deploy are two very different actions. Sharing the same config for both actions are problematic, e.g., You can build a Wasm module and deploy the Wasm many times. This is not possible to specify in dfx.json at moment (You can hack it by duplicating the canister entries, but it's a hack)

The latest update to Mops introduced a dependency version pinning feature. So now it is possible to have 2 or more version of the same package in a project.

Interesting! I wonder how you implemented use case 2. For package with "base@0.11.0" = "0.11.0", does the author has to use import Int "mo:base@0.11.0/Int" in their code?

[ZenVoich]

Interesting! I wonder how you implemented use case 2. For package with "base@0.11.0" = "0.11.0", does the author has to use import Int "mo:base@0.11.0/Int" in their code?

Yes, the package name is base@0.11.0

One question is how strict we should follow the toolchain version. A library may be written years ago and pinned to an old release. But it may run just fine with the latest moc.

[toolchain] section of dependencies is ignored. So it has effect only in project's mops.toml.

There is a [requirements] section for dependencies to define minimum required moc as a hint.