You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
It's common to have
library
andtest
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 underneathtest/
. And requires running test commands from withintest/
, but I also don't hate having thetest
specific configuration in thetest/
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 atest.dhall
file and call something likevessel -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 forvessel
.Related to/Generalizes #7
The text was updated successfully, but these errors were encountered: