If I only update trigger code can I rebuild DAML and rerun the trigger? Or do I have to restart everything else (Sandbox, JSON API etc.)?
That depends on how you setup your packages.
If your templates and triggers are part of the same package, then modifying your trigger code and recompiling the package will change the package id of everything included in that package so the package id of the templates changes and you have to upload the new DAR to the ledger (you don’t necessarily have to restart it though if you are fine with two versions of the template existing on the ledger).
If your templates are in one package and the triggers in another package which depends on the templates, then you only ever need to upload the DAR for the templates to the ledger. Modifying the trigger code will then only modify the package id of the triggers and there is no need to reupload anything to the ledger.
Makes sense.
What does it mean to have two versions of a DAR on a ledger?
Does separating packages mean multiple “DAML projects”, i.e. daml.yaml
s?
What does it mean to have two versions of a DAR on a ledger?
To the ledger those are two completely unrelated DARs (or rather the main DALFs in the DARs are unrelated).
Does separating packages mean multiple “DAML projects”, i.e.,
daml.yaml
s?
Yes, make two separate projects and use the data-dependencies
field (or dependencies
) to depend on the templates DAR from the trigger project. I would always recommend splitting things this way for triggers and DAML Script exactly so that you can modify them without changing your templates. Of course, for demos it’s still fine to keep them together if you want.
Separations seems like a good practice to (start to) follow.
How well does VSCode support this? Will it pick up the changes in the dependencies, will it understand the modules and types from the dependencies, etc?
It won’t pick up changes to dependencies. You have to manually run daml build
to produce the DAR of your dependency and reload VSCode. It will understand modules and types but atm things like go to definition are not supported accross package boundaries.
Rebuild is fine, I expected that. And while a bit inconvenient a VSCode restart is fine as well.
It’s good that after that the experience would be the same.