Do people actually use vessel?

I’m at the point where I want library-level unit testing, and it seems like the general recommendation is to use motoko-matchers.

To install that, it seems like I also need to install vessel and point my package-set.dhall file to the latest version of vessel-package-sets.

Here’s a couple issues I saw from doing research:

  • vessel-package-sets seems pretty out-of-date… it’s stuck at Motoko v0.6.8, which is older than the current version of v0.6.14
  • vessel-package-sets needs to be regularly maintained to work properly, since it only supports a single version of any library, unlike package.json in JavaScript… that seems problematic, and it’s also not regularly maintained
  • Does motoko-matchers require wasmtime to actually run tests? The documentation isn’t clear
  • motoko-matchers was last tested on Motoko v0.5.8
  • There doesn’t seem to be a good reason to use vessel if you’re not using vessel-package-sets

Any help would be appreciated. Thanks!

2 Likes

A bit of staleness is not unexpected, as the main author of vessel, @kritzcreek, has left DFINTY a while ago.

That said, vessel is probably still the best way to manage dependencies (short of vendoring them, or maybe git submodules), and I use it in all my (toy) project when I need extra libraries such as sha256 . For example, in GitHub - nomeata/motoko-certified-http: A motoko canister that can server certified HTTP assets I am using vessel to pull in GitHub - nomeata/motoko-merkle-tree: A merkelized key-value store for Motoko (or rather, I did until I applied some simplifications).

It would probably be good to have more libraries on

https://dfinity.github.io/vessel-package-set/

But I agree that more active maintenance of the package set is lacking. But is it the cause of a problem, or a symptom?

2 Likes

vessel-package-sets seems pretty out-of-date… it’s stuck at Motoko v0.6.8, which is older than the current version of v0.6.14

It’s the latest compiler version CI tested against. Given that v0.6.14 just has patch bumps compared to v0.6.8 I’m assuming that the package-set should work just fine with the newer compiler version. There’s no reason to release a new package-set if none of the packages changed their versions. But updating the compiler version used on CI also isn’t hard.

vessel-package-sets needs to be regularly maintained to work properly, since it only supports a single version of any library, unlike package.json in JavaScript… that seems problematic, and it’s also not regularly maintained

npm’'s dependency model puts the onus on every single developer to try to keep their individual project building on a foundation of shifting dependencies underneath them. With the package-set approach we can share that work of making new versions of dependencies build together and then contribute the compatible version updates back upstream. Now that doesn’t stop you from maintaining your own project-local package-set like you’d do with package.json.

Does motoko-matchers require wasmtime to actually run tests? The documentation isn’t clear

That’s how I’ve run them so far. You can totally compile a Motoko actor and have it run matchers tests on the replica, though the feedback cycle would be much slower. I have an example of doing that here: GitHub - kritzcreek/ic101

There doesn’t seem to be a good reason to use vessel if you’re not using vessel-package-sets

vessel-package-sets forms a reasonable basis of “These are commonly used packages”. But, if you have your own, maybe company internal?, set of packages you like to use and share you can extend it or build your own package set. I know that Aviate Labs have done that for their collection of Motoko libraries: GitHub - aviate-labs/package-set: Aviate Labs' package set for Vessel

Here’s a cool example of a library that uses both dfinity/vessel-package-set and combines it with aviate-labs/package-set to collect all the dependencies it needs.

Having more active maintenance of vessel-package-set would certainly be nice, but my priorities have shifted around a bit, so it would require involvement of the community. There’s certainly nothing particularly hard about it, it’s just work.

6 Likes

Thanks, this is really helpful.

With the package-set approach we can share that work of making new versions of dependencies build together and then contribute the compatible version updates back upstream.

Can you explain how the package-set approach this? From what I can tell here, library maintainers still have their work cut out for them, as they need to continually update their dependencies if other packages/libraries use a newer version of a dependency they also use.


As an aside, I’m curious why vessel uses a different moc binary than the one shipped with dfx by default. Why not use the same moc as the one shipped with the version of dfx specified in the user’s dfx.json?

For example, I’m currently stuck on dfx 0.7.1, which I believe uses Motoko 0.6.1. But the vessel-package-set is currently tested on Motoko 0.6.7.

If I install vessel and use that latest vessel-package-set, then my canister code will be compiled with moc 0.6.1 but my dependency code will be compiled with moc 0.6.7. Isn’t that a problem? (I suppose, as you mentioned, semver means that 0.6.7 is backwards compatible with 0.6.1, but one day they’ll have to bump to 0.7.x.)

Or is this where I should change the compiler field in vessel.dhall?

Not sure what the difference between that and the version in vessel verify --version 0.6.1 is…

1 Like