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

[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 :stop_sign: 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 :construction: and TLC :purple_heart:, 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 :evergreen_tree: :deciduous_tree: :palm_tree: . Additionally developers from the Motoko bootcamp (brand new to devs to Motoko and the IC) also hit some of these pain points :point_down:

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 :disappointed: .

The Solution

Step 1) - Community Feedback :people_holding_hands:

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** :muscle: gives their feedback :brain:

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 :point_down: 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 :memo:

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

9 Likes

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.

7 Likes

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

5 Likes

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

8 Likes

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:

3 Likes

@rvanasa the mops method is my vote as well.

2 Likes

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.

4 Likes

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

2 Likes

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).

1 Like

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

3 Likes