Proposal: Depending on DAR packages shipped with the SDK

[cocreature]

Currently, depending on a DAR package requires specifying a relative or absolute path to the DAR. This does not work well if we want to start distributing libraries with the SDK, e.g., I would like to ship a prototype of DAML triggers soon which will require shipping the trigger library.

I propose that we extend the dependencies field in daml.yaml to support paths of the form $SDK/lib.dar which will automatically be resolved to something like ~/.daml/sdk/$CURRENT_SDK/daml-libs. That should be easy to implement and reasonably easy to use and makes it feasible to commit this in your repository.

cc @associahedron as the benevolent dictator of the assistant and @Robin-da and @nickchapman-da for general packaging questions and @bame-da for UX feedback.

[bame-da]

$SDK/lib.dar is inconsistent with std-lib and ghc-prim. I'm not opposed to special treatment of SDK-included packages, but think there should only be one mechanism.

[cocreature]

That’s a fair point. daml-stdlib and daml-prim will always be special, e.g. they are not shipped as .dars and they are always in scope whereas these packagase won’t be in scoe implicitly. But that might not be something that we want to expose users to.

If we want to make them uniform, we could assume that all dependencies that do not end with .dar are shipped with the SDK and treat them specially. Does that sound reasonable?

So then you would specify dependencies: - lib and we internally translate that to something like ~/.daml/sdk/$CURRENT_SDK/daml-libs/lib.dar.

[ghost]

@cocreature I like that. I like the simplicity & uniformity of:

dependencies: 
- daml-prim
- daml-stdlib
- daml-triggers