Is there a way to unpublish or yank a specific version of the package from mops?
There is no such functionality yet, but I think it will be implemented in the future
Update
Transfer ownership
New command mops transfer-ownership <principal>
will transfer ownership of the current package to the specified principal. After transfer you will no longer be able to publish this package.
GitHub dependency commit hash
Now when you add github package by mops add https://github/...
mops will add commit hash to the package url. This will provide sustainable and reproducible builds, so new commits to a branch will not break your code.
How it looks like <url>#<branch_or_tag>@<commit_hash>
Also you can update commit hash to the latest with mops update <package_name>
Mops Documentation
New Mops documentation site: https://docs.mops.one/
Benchmarking tool
Now Mops includes benchmarking tool mops bench
.
Learn more here https://docs.mops.one/cli/mops-bench
and here https://mops.one/bench
New packages published on mops
- evm-proof-verifier - EVM Proof Verifier in Motoko
- memory-region - An abstraction over the Region type that supports reusing deallocated memory.
- ic-websocket-cdk - the Motoko implementation of IC WebSocket CDK
- memory-buffer - A persistent buffer implementation in motoko.
Would it be possible to delete a package and republish it with the same name and the same versions except last with the same identity?
I think it should not be possible to republish a deleted package. What case are you thinking about?
In order to remove the version that I don’t want to be public anymore, I could remove the whole package and republish it with all the previous versions except the version that I wanted to remove. But that’s not possible as far as I understand.
@ZenVoich this class’ description should appear as a bullet points list, but it’s rendered as plain text. Should I use *
for the bullets instead?
Screenshot source: https://mops.one/ic-websocket-cdk/docs/lib#type.WsInitParams.
Source code reference:
Also, is there a way to reference other functions by name in the docs? Something like Linking to items by name - The rustdoc book.
I know it may not be the right thread to ask these things…
Yes, I think * should work. I see base
package uses it
Not sure if mo-doc
supports this - [mo-doc] Allow users to write Xrefs in their doc strings · Issue #2352 · dfinity/motoko · GitHub
Also related [mo-doc] Cross-reference other packages · Issue #2350 · dfinity/motoko · GitHub
I see the base package uses -
for bullet points, e.g. in:
So I might just need to add an empty line before the list.
Update
Toolchain Management
Now you can specify moc/wasmtime/pocket-ic version for each project!
Initialize moc version management(run once):
mops toolchain init
Install specific moc
version:
mops toolchain use moc 0.10.3
Update moc
to the latest version:
mops toolchain update moc
Update all tools:
mops toolchain update
Lear more: https://docs.mops.one/cli/toolchain
Tests page update
Tests tab on mops.one now supports nested tests.
Click on [source]
link will open test source file on GitHub.
Bench updates
- Added support for
pocket-ic
replica via--replica pocket-ic
flag.
mops bench --replica pocket-ic
-
The default garbage collector is now
--copying-gc
(was--incremental-gc
) -
Colorized output for
mops bench --compare
Lockfile support
mops.lock
is used to ensure integrity of dependencies, so that you can be sure that all dependencies have exactly the same source code as they had when the package author published them to the Mops Registry.
Learn more: https://docs.mops.one/mops.lock
New packages in the mops registry
- promtracker - Motoko value tracker for prometheus
- xrc-types - Exchange Rate Canister interface
- account - A Motoko implementation of ICRC-1 and ICRC-7 Accounts
- rep-indy-hash - Representationally Independent Hash for motoko
- icrc1-mo - icrc1 for motoko
- icrc3-mo - icrc3 for motoko
- icrc7-mo - icrc7 for motoko
- icrc30-mo - icrc30 for motoko
- augmented-btrees - Contains implementations of BTree variants, most notable the B+Tree
Mops Update
Package Code Explorer
Now you can see the actual source of the package published on mops registry!
For example base package source code: https://mops.one/base/code
There is a new [source]
links in the package documentation, click on it to jump to the source code of that class/function/variable/type.
Local package’s transitive dependencies
Mops now resolves nested dependencies for local packages too.
Package Repository Verification
When publishing a package to the Mops Registry, mops canister will check if the package repository actually has a mops.toml
file with specified package name. Therefore, it is no longer possible to publish other people’s packages with a link to the original repository.
GitHub action setup-mops
Super easy way to use mops in your GitHub actions, just add one step:
- uses: ZenVoich/setup-mops@v1
This also will cache mops packages, so subsequent actions are faster and prevent from http errors when you run a lot of concurrent actions.
Also you can use this action to publish a packge on mops, see example GitHub - ZenVoich/setup-mops: GitHub Action to to set up Mops
or run mops template
and select “GitHub Workflow to publish a package”
Mops Update
Package benchmark results on mops.one
On mops publish
package benchmarks are run and published with package.
You can see benchmark results on “Benchmarks” tab
Also you can see the difference in results between two versions in “Versions” tab
Keep clean .mops
folder
Now on mops install
no intermediate packages installed in .mops
directory, only final resolved versions of packages.
Mops CLI on-chain
Now mops cli builds are distributed via on-chain storage!
Check out https://cli.mops.one
To install from on-chain storage use this command:
curl -fsSL cli.mops.one/install.sh | sh
New command mops self update
Docs mops self update | Mops Docs
Use mops self update
to update mops cli to the latest version (available since 0.41.0
)
Package requirements
Docs mops.toml file | Mops Docs
Now packages can specify which moc
version is required for this package.
Example mops.toml:
...
[requirements]
moc = "0.11.0"
The package requirements will be show on the package page:
When a user installs your package(as a transitive dependency too), Mops will check if the requirements are met and display a warning if they are not.
Thanks for the updates.
Some questions:
Does ZenVoich/setup-mops@v1.2.0
use the on-chain version or something else? Shall we use curl -fsSL cli.mops.one/install.sh | sh
in CI?
Is it recommended to put in the [requirements]
section the lowest moc
version number that works? For the [dependencies]
section my mental note was to put the highest version number. But here it’s the lowest, or?
At the moment it uses npm registry. Later I think I will change it to on-chain…
Also I still continue publishing new releases to npm registry too. So no need to change CI scripts
Yes. For example, if you are sure that moc version lower than 0.10.0 will not work with your package, set it to 0.10.0 (even if there are newer versions available)
Got it. Thanks. Just noting that this requirement could be introduced by the dependencies I use. Say for example my code works with any base
dependency >= 0.9.0. Then I put
[dependency]
base = "0.11.1"
[requirements]
moc = "0.10.0"
in mops.toml because 0.11.1
is the most recent base version. But it is base 0.11.1
that has the moc >= 0.10.0
requirement, not my code. My code may actually work with base 0.9.8 in which case I can make it
[dependency]
base = "0.9.8"
[requirements]
moc = "0.9.0"
I guess the first version is still better even though it does not lead to the minimal moc version.
Check out the new blog post with Mops updates!
- Common nav bar
- Mops CLI updates
- Dependency version pinning
- GitHub Action update
- Documentation updates
- GitHub dependency name restrictions
New blog post with the latest Mops updates!
- Mops CLI 1.0.0 release with breaking changes
- Verifiable cli builds
- New “Stable Memory” and “Garbage Collection” benchmark metrics
- Motoko tests running in replica
just wanted to leave some credit for @ZenVoich. very cool and important project, keep up the great work!