[Developer Feedback Opportunity]: Motoko Package Manager Improvements/Redesign

[icme]

[Developer Feedback Opportunity]: Motoko Package Manager Improvements/Redesign

The Problem

Those familiar with the Motoko ecosystem have used Vessel, and may or may not have run into various issues in using it along the way.

Vessel has been a great package manager tool to get Motoko off of the ground (developed back in 2019-2020?), but at this point in time the ecosystem has grown to the point where it needs more active improvements and TLC , or a hard deprecation and switch to put time and effort into a completely different package manager.

For example, with Vessel it is quite difficult to set up and maintain projects that have more complicated dependency trees . Additionally developers from the Motoko bootcamp (brand new to devs to Motoko and the IC) also hit some of these pain points

Please kindly improve setup

This greatly impacts developer productivity, even to the point where developers I’ve worked with lose several days of time due to cryptic Vessel issues .

The Solution

Step 1) - Community Feedback

I know that the Motoko team is well aware of the limitations of Vessel, and would like to dedicate resources to either improve, or completely redesign the Motoko package management experience.

However, dedicating resources is much easier when the community **that’s you** gives their feedback

At this point, I don’t want to speculate on what the Motoko package manager of the future will look like, but first want to open up the discussion for Motoko developers (and even Rust developers or others that used and bounced off of Motoko) to give any and all ideas and critical feedback that you have.

If you need a format/structure - use the below to talk about:

1. The experience of using Vessel, especially the current pain points/friction you or others you know have when using Vessel.
2. The package managers you enjoy using the most, and why you enjoy using them?
3. The developer experience you would like to have when building an IC application.

Step 2) - Feedback Consolidation and Feature Scoping

Once the community completes the feedback portion, this will make is 10X easier for the Motoko team & community to boil down the essence of the necessary improvements, and start scoping out these changes and any necessary redesign.

Step 3) - Package manager improvements

[rvanasa]

Thanks @icme!

We are currently evaluating whether to continue updating Vessel or to support the development of MOPS, a community package manager which I personally think is a great addition to the Motoko ecosystem.

For anyone who’s currently reading this, we would love to hear from you in this forum topic or on the dfinity/vessel GitHub repository.

[Gekctek]

Vessel likes:

• attaching the compiler version to vessel config and using ‘vessel bin’

Dislikes:

• config file format. Not sure what it is
• no repository, just a git repo/linking to other git repos
• confusing how to configure the base library version, have to override

Mops likes:

• Canister repository with ability to publish to it
• easier config

Dislikes:

• no compiler download/config
• npm

I think it might make sense for something like vessel to have 1+ registries to use that are community maintained. Or at least to be able to choose a registry to point to vs a single registry for everything

Cc @ZenVoich @tomijaga since they work on MOPS

[jorgenbuilder]

I like the deno syntax of importing a URL. Is that possible for Motoko, and could that cut out the need for using vessel via the CLI?

import MyPack "https://github.com/me/my-pack.git";

Would people like that? I don’t have a strong argument to make here, it just seems convenient

[rvanasa]

What do you think of the way MOPS approaches this feature?

For example, it’s possible to run

mops add https://github.com/me/my-pack

with an optional branch, tag, or commit hash. I personally think that this is a reasonable compromise in the sense that URL imports could become a reproducibility issue for larger-scale projects, whereas a CLI could autogenerate the SHA256 or Git commit hashes of dependencies. That being said, URL imports are super convenient in Deno and the browser, and I’m curious to hear more opinions on this.

Here is a thread which covers some of the subtleties of URL imports (Deno) vs. a package registry (npm):

Context for how Deno handles URL imports:

Linking to external code | Manual | Deno

[Gekctek]

@rvanasa the mops method is my vote as well.

[skilesare]

@Gekctek

no repository, just a git repo/linking to other git repos

This is actually my favorite part of vessel. I love that I don’t have to register anything anywhere. Just make sure I have an src folder, push to github, and then tell someone the repo. If I want to change something in the repo I can fork and get rid of their Array.appends without waiting for a pull request.

If vessel had a recursive look up and loaded packages of my packages I wouldn’t change much. Maybe a website/service where we could load by name…I guess a json format for the config file would be nice also.

vessel install https://github.com/skilesare/myrepo ← would be nice.

[skilesare]

@jorgenbuilder

import MyPack "https://github.com/me/my-pack.git";

This would be sweet if we could indicate the version we want.

[rvanasa]

I would be curious to hear your impressions or wishlist for MOPS if you decide to give it a try, since my understanding is that it currently includes all of these features aside from URL imports (and uses TOML in place of JSON).

[rbolog]

Hello,

I must admit that I am not familiar with MOPS and Vessel did not give me what I expect from a package manager.

Basically what I expect is that it simplifies my life with a minimum investment of time. Personally I found that the balance between time invested and time or quality gained was not enough with Vessel so I preferred to solve this with shell scripts and manual package of Gitab.

If I compare with Rust using crates.io + cargo, there are features like:

• Full text or tag search, etc.
• See the number of downloads,
• See the activity
• The documentation
• If this package is used in other projects
• If the dependencies are up to date etc,…
• The publish fonction is also easy and it checks some minimum requirements

So I can easily guide my choice and the integration in my project is extremely simple, the update too. At no time I have to go in the git of cargo or crates.io to understand their functionalities. The use of a github link or others seems to me not very sustainable for the long term. Imagine in a few years with complex applications with a lot of dependencies, the maintenance to go on the repositories to evaluate if the project is maintained or not the minimum compatible version and if you have to find a replacement explore github, gitlab, bitbucket, gitea,… to find some things. So for me a package manager is not only the ability to make a clone of a repo and to launch the build.

And there is also the license management…

Regards

[tiago89]

Only today saw this.

If it’s still worth something, I think I could chime in a few key points.

I was in the last bootcamp, vessel was an issue (as stated by the OP) and this week had another bootcamp, and I built a starter-template that had MOPS in it. In large dozens/low hundred of people that used it, I don’t recall anyone having any specific problem with it.
Which is pretty impressive.

There were a couple of students (around 5) that reported having issues with using Node, and node versions / path (maybe due to be in Windows or being an old install). But these were issues with Node and not MOPS itself. It does not matter what stack you work with, there will always be setup problems, nonetheless, due to Node being so ubiquitous, think it’s the stack that will give the lowest chance of being a problem.

I have been using Ryan’s “mo-dev” npm package, and I am aware of how fast (and easy) node can be at running things in the backend. Also we have Azle using typescript (and using node). I am also building a spec library that uses node as a runner (with mo-dev), etc. So in short, I am seeing node staying and does not confuse me much to always see a package.json even if the project is only a Motoko one.

Specifically about MOPS, I like:

• As a package “maintainer” it’s easier to publish and get stats. MOPS has, in exact same fashion as NPM. Vessel does not have, and have the impression that it can’t have. I don’t even recall ever seeing a page of Vessel Packages
• As a package “user” it’s important to search for packages, through a list but also through keywords. It’s important that it can be easily indexed by search engines and anyone can easily read and download it. Same as last point, MOPS has it, Vessel can’t, or at least doesn’t.
• Vessel works with “Package Sets” which I’ve always found an “inefficient” concept. I am aware of base and quint’s package set, and it’s still strange to download a series of packages. In MOPS this is not so needed/common as you can easily search and add packages.
• The commands of vessel seem pretty limited, compared to MOPS (and MOPS is still missing an “outdated” command )

Overall, my personal vote goes towards officially deprecating vessel. Hopefully MOPS can be considered a better package by Dfinity and the community. Having a strong package manger will allow for a strong community to inter-support itself.

I hope the maintainers also can be open for Dfinity and the Community to help maintain it. We all also will have a role on it’s future success.

Thanks.

PS: just tagging @rvanasa and @ZenVoich to be aware of this.