search

dfinity / vessel

The original package manager for Motoko
Apache License 2.0
112 stars 19 forks source link

Let users specify different targets #26

Open kritzcreek opened 3 years ago

kritzcreek commented 3 years ago

It's common to have library and test targets with different dependencies and I can think of more possible targets like benchmarks, or maybe even canisters/canister blueprints.

In my library template I "solve" this by referencing the main vessel.dhall from the test folder and extending it using Dhall. It's not ideal because it creates a separate .vessel directory underneath test/. And requires running test commands from within test/, but I also don't hate having the test specific configuration in the test/ directory rather than adding it to the library config.

Possible Solution 1: spago solves this by letting the user specify a config file to use instead of the default one. So you'd create a test.dhall file and call something like vessel -x test/test.dhall sources.

Possible Solution 2: cargo and most other package managers let the user specify their multiple targets in the main manifest file, We could come up with a schema to do the same for vessel.

Related to/Generalizes #7

matthewhammer commented 3 years ago

Seems like "possible solution 1" is what I actually did in practice, and that vessel already supports this now, via --package-set?

My interpretation of solution 2 (the popular way / the "cargo way") is as a systematic pre-arranged structure for these extra files' contents, and rules about combining them (example binaries vs test libraries and binaries vs "main crate"), though I may not appreciate what cargo is doing entirely.

matthewhammer commented 3 years ago

Seems like "possible solution 1" is what I actually did in practice

And IIUC, I could refactor these files to reduce the redundancy and have one use the other, following what you do in the library template. I am taking Dhall baby steps for now, but I think that's another natural baby step in the right direction.