[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

6 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

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

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 :confused:
  • 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 :stuck_out_tongue:)

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.

5 Likes