Feature Requests

[q-uint]

Here are some feature requests that would greatly improve the functionality of the Vessel package manager (from my perspective):

• The sources command should not attempt to install packages. This can sometimes cause issues with Vessel when using it offline. It would be better if sources only fetched the package source code and did not try to install anything.

• Private repository support has been requested previously in issue Support private library imports #62. It would be great to have the ability to use private repositories in Vessel.

• Monorepo support would be very helpful. It would be nice if the repository could declare custom subpackages, or if users could do it themselves. This would make it easier to manage large codebases with multiple packages. (Support multiple packages in one repository. #38)

• Autodiscovery of dependencies would be a great addition to Vessel. If a dependency already has a vessel.dhall file, Vessel could automatically detect it and add it to the project's dependencies.

• The src dependency should be removed. This is a restriction that is not necessary and prevents Vessel from being used with other languages. Removing this restriction would make Vessel more flexible.

• A simple install command would be very useful. Vessel could autogenerate everything based on the downloaded repository, with or without a vessel.dhall file. This would make it much easier to install packages and get started with Vessel.

• Using json/yaml instead of dhall would improve usability for most users. While dhall is a powerful tool, it can be difficult to use for beginners. Providing options to use json/yaml as alternative configuration formats would make Vessel more accessible to a wider audience. (Proof of concept: add 'vessel.mo' as an alternative to 'vessel.dhall' #59)

I made an experimental package manager to test some of these features out, which can be found here.

[rvanasa]

Noted! Thank you for the list of requests, and I personally agree with all of them. We will make sure to account for these in a future backwards-compatibility-breaking version of Vessel.

[crusso]

@di-wu thanks for taking the time to make this wish list!

[q-uint]

Thanks @rvanasa and @crusso.
Feel free to involve my in the process, I'd be happy to help by assisting with feature implementation and code reviews.

[kritzcreek]

Thank you very much for putting this list together! I'll give feedback to the individual points below. Mostly from a perspective of "What desirable features does the current design of vessel prohibit?"

The sources command should not attempt to install packages. This can sometimes cause issues with Vessel when using it offline. It would be better if sources only fetched the package source code and did not try to install anything.

The reasoning at the time was to reduce friction because you only get the one packtools command to integrate with dfx. But obviously an offline mode would be possible with the current design.

Private repository support has been requested previously in issue

#62. It would be great to have the ability to use private repositories in Vessel.

vessel works just fine to install private repositories, you just can't reference private repositories to host dhall files. I'm not sure if this is a misunderstanding, or if people really need to host private package-set files. (Either way this would be a limitation of the dhall implementation in Rust, not of vessels design)

Monorepo support would be very helpful. It would be nice if the repository could declare custom subpackages, or if users could do it themselves. This would make it easier to manage large codebases with multiple packages. (#38)

I think adding the feature from #38 would be a simple first step towards allowing this, yeah. I'm not sure I would call that monorepo "support" as you'd probably want to to think a fair bit about declaring and sharing common dependencies.

Autodiscovery of dependencies would be a great addition to Vessel. If a dependency already has a vessel.dhall file, Vessel could automatically detect it and add it to the project's dependencies.

I'm sorry I don't follow. Could you write up an example of how this would work? (Note that one important feature of vessel is that a repository doesn't need a vessel.dhall file for it to be used as a dependency)

The src dependency should be removed. This is a restriction that is not necessary and prevents Vessel from being used with other languages. Removing this restriction would make Vessel more flexible.

Same point as the monorepo one I think? Agreed, the src directory is just a convention that should be overridable with configuration.

A simple install command would be very useful. Vessel could autogenerate everything based on the downloaded repository, with or without a vessel.dhall file. This would make it much easier to install packages and get started with Vessel.

I also don't understand this one. What's the downloaded repository, what do you think requires a vessel.dhall file?

Using json/yaml instead of dhall would improve usability for most users. While dhall is a powerful tool, it can be difficult to use for beginners. Providing options to use json/yaml as alternative configuration formats would make Vessel more accessible to a wider audience. (#59)

You could build something that uses JSON or YAML but you'd need to basically build a DSL on top of them that replicates some of the more complicated features of dhall. I don't know how good the ROI on this one would be, but if someone wants to try to build the features vessel needs on top of a JSON dsl we can compare the outcomes.

[q-uint]

Could you write up an example of how this would work?
What's the downloaded repository, what do you think requires a vessel.dhall file?

It basically comes down to this:

1. I want to add package B as a dependency to package A.
2. Adding package B to the vessel.dhall config does not suffice since package B also has dependencies on its own.
3. So you also need to copy-paste the package-set.dhall dependencies from package B.

I would be nice if this could be done for you, by adding another cli command f.e..

I.e. vessel install github.com/aviate-labs/crypto.mo would add the package as a dependency and also add it’s (sub-)dependencies specified in package-set.dhall.

[kritzcreek]

Adding package B to the vessel.dhall config does not suffice since package B also has dependencies on its own.
So you also need to copy-paste the package-set.dhall dependencies from package B.

That's not quite right... if you have B with a dependency on C you can add B to your projects dependencies and it will install C as well. Those dependencies need to be defined in the package-set. Is your plan to transitively traverse all these github repos to build the package-set entry? I think it would be much easier if people just added their packages to https://github.com/dfinity/vessel-package-set.
It requires very little maintenance and makes it easier to keep an ecosystem of packages that compile with each other for everyone to use.

[q-uint]

Sorry, I probably did not phrase that right.

So you also need to copy-paste the package-set.dhall dependencies from package B.

* into your own package-set.dhall file.

---

I am not convinced people experience this as easy. Since nobody seems to be adding their packages to the package set.
I've been using my own package set to work around the issue described above.

As long that packages do not depend on each other, it requires very little maintenance. To which I experienced the contrary while trying to maintain over 25 packages and keeping them up to date with the latest Motoko version.

There is also a limitation that does not allow you to nest package sets themselves.
I.e. I want to add dfinity/vessel-package-set to the aviate-labs/package-set.