Mops - on-chain package manager for Motoko!

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

1 Like

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/

:rocket: 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

:package: New packages published on mops

2 Likes

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

1 Like

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

:rocket: Toolchain Management

image

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

:arrow_up: Tests page update

Tests tab on mops.one now supports nested tests.

Click on [source] link will open test source file on GitHub.

image

:arrow_up: 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

:new: 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

:package: New packages in the mops registry

7 Likes

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”
image

7 Likes

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:
image

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.

6 Likes

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
2 Likes

:sparkles: 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
9 Likes

just wanted to leave some credit for @ZenVoich. very cool and important project, keep up the great work! :+1:

4 Likes