DAML source code for modules incorporated through dependencies

Questions
1

Looking at the Danban OpenWork project, v3.1 of the model is implemented mostly through a dependency on v3.0. (The 3.1 model is the 3.0 model, plus an additional contract template or two).

dependencies:
  - daml-prim
  - daml-stdlib
  - ../V3/.daml/dist/danban-v3-3.0.0.dar

While this seems like a good way to extend a model, the source code for the 3.0 model does not appear to be included in the compiled 3.1 DAR. (And so, you can’t see the source for the majority of the contract templates in DABL.) This leads me to three questions:

  • Is this understanding correct, and dependency source missing from the compiled output? (Looking at the list of files in the DAR, it appears the answer is yes.)
  • is there any way to change this behavior and integrate the sources of a dependency into a DAR file?
  • What’s the best practice here, to ensure that all the relevant code is included in a DAR file? (It seems unfortunate to force the V3.1 DAR to recompile the V3.0 contract templates just to get the source, given that this would, I think, result in new contract template ID’s for unchanged templates.)
4 Likes
2

First, note that Danban is on a very old SDK so please don’t use it as a reference for how you can extend models in recent SDKs. In particular, you should make use of the data-dependencies feature in recent SDKs instead of using dependencies since the latter does not work accross SDK versions. You can find more information at https://docs.daml.com/upgrade/index.html.

Now on to your actual question: You are completely right that source code of dependencies does not get included. This is currently tracked in Include DAML files from DAR dependencies · Issue #3617 · digital-asset/daml · GitHub. As a user there is currently no way for you to fix this.

While we could make this work in the compiler in some cases, there are quite a few issues with this feature:

  1. In particular, for data-dependencies we do not necessarily have the source code available. E.g., if you got your DAR from daml ledger fetch-dar it will never contain source code since the ledger does not store anything but the DALFs in a DAR.
  2. Some DALFs (e.g. the one containing the definition of Either) are “hand-crafted” in the sense that we’ve written DAML-LF directly instead of compiling DAML (I won’t go into the reasons here) so there never was any source code.
  3. It is completely unspecified where in the DAR the source code ends up. This becomes more of a problem if you have multiple packages that becomes even more of a problem since now you need to namespace them somehow to handle module collisions.

So to summarize, while it would be possible to make this work in some cases there are fundamental issues with including source files since you can depend on packages without having their source code. There are good reasons to do so (hand-crafted DALFs and daml ledger fetch-dar). I still think that it would be nice to include the source files if they are available but you definitely cannot rely on source files being available in all cases.

3 Likes