Open chenyan-dfinity opened 1 month ago
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 - https://github.com/ZenVoich/mops/issues/165#issuecomment-1809879775
Some motivations for this project:
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.dfx build
command. With the this mops cli, dfx build will simply call mops build
for Motoko canisters, and cargo build
for Rust canisters.
- 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 callmops build
for Motoko canisters, andcargo 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 https://github.com/dfinity/motoko/issues/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.
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?
Interesting! I wonder how you implemented use case 2. For package with
"base@0.11.0" = "0.11.0"
, does the author has to useimport 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.
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 :)