# \[Developer Feedback Opportunity\]: Motoko Package Manager Improvements/Redesign **URL:** \ **Category:** Language Support\ **Tags:** Motoko\ **Created:** [January 23, 2023, 7:17pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137 "2023-01-23T19:17:05Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [January 23, 2023, 7:17pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/1 "2023-01-23T19:17:05Z")
# [Developer Feedback Opportunity]: Motoko Package Manager Improvements/Redesign ## The Problem Those familiar with the Motoko ecosystem have used [Vessel](https://github.com/dfinity/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 šŸ‘‡ > > > Hi, > > My name is Tiago and am on the Motoko Bootcamp. I really like everything ā€¦I have seen about Dfinity and ICP. > > But this package manager is really raw :( And it makes it super hard to reuse code from other community members. > > The end result is the bad practice that have seen a lot, that is to literally copy paste code from github to internal projects. But that is not maintainable nor scalable. The more time passes, the bigger is the tech debt of all of us. > Please kindly consider making vessel a priority again šŸ™ > > I tried to install vessel and Mac (rightly so) does not allow for a source file to be imported from the internet and be executed without proper verification: > \Screenshot 2023-01-20 at 18 39 23 > > Hope this can be eventually sorted out. > > Thank you, > Tiago L. 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 šŸš€ šŸ¤˜ ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [January 23, 2023, 9:09pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/2 "2023-01-23T21:09:57Z")
Thanks @icme! We are currently evaluating whether to continue updating Vessel or to support the development of [MOPS](https://github.com/ZenVoich/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](https://github.com/dfinity/vessel/issues) GitHub repository. ---
**Author:** ![Gekctek](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gekctek/32/6863_2.png) [@Gekctek](https://forum.dfinity.org/u/Gekctek)\ **Post date:** [January 26, 2023, 11:29pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/3 "2023-01-26T23:29:03Z")
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 ---
**Author:** ![jorgenbuilder](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jorgenbuilder/32/22166_2.png) [@jorgenbuilder](https://forum.dfinity.org/u/jorgenbuilder)\ **Post date:** [January 28, 2023, 7:12pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/4 "2023-01-28T19:12:22Z")
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 šŸ™‚ ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [January 31, 2023, 12:36am UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/5 "2023-01-31T00:36:59Z")
What do you think of the way MOPS approaches this feature? For example, itā€™s possible to run ```bash 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): > > > Does anyone else see the import directly from URL as a larger security/reliability issue than the currently imperfect modules?\I'm sure I'm missing something obvious in that example, but that capability terrifies me. Context for how Deno handles URL imports: > **[Linking to external code | Manual | Deno](https://deno.land/manual@v1.17.1/linking_to_external_code)** > > In the \[Getting Started\](./getting\_started.md) section, we saw Deno could > execute scripts from URLs. Like browser JavaScript, Deno can import libraries > directly from URLs. This example uses a URL to ---
**Author:** ![Gekctek](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gekctek/32/6863_2.png) [@Gekctek](https://forum.dfinity.org/u/Gekctek)\ **Post date:** [January 31, 2023, 12:41am UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/6 "2023-01-31T00:41:00Z")
@rvanasa the mops method is my vote as well. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [January 31, 2023, 1:14pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/7 "2023-01-31T13:14:26Z")
> [@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](https://github.com/skilesare/myrepo) ā† would be nice. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [January 31, 2023, 2:11pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/8 "2023-01-31T14:11:35Z")
> [@jorgenbuilder](#): > > `import MyPack "https://github.com/me/my-pack.git";` This would be sweet if we could indicate the version we want. ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [February 2, 2023, 7:56pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/9 "2023-02-02T19:56:41Z")
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). ---
**Author:** ![rbolog](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rbolog/32/239_2.png) [@rbolog](https://forum.dfinity.org/u/rbolog)\ **Post date:** [February 2, 2023, 9:05pm UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/10 "2023-02-02T21:05:16Z")
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](http://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](http://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 ---
**Author:** ![tiago89](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/tiago89/32/22332_2.png) [@tiago89](https://forum.dfinity.org/u/tiago89)\ **Post date:** [May 13, 2023, 7:09am UTC](https://forum.dfinity.org/t/developer-feedback-opportunity-motoko-package-manager-improvements-redesign/18137/11 "2023-05-13T07:09:09Z")
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.