We bumped into an issue of packageId hash changes non-deterministically when we did not change any daml codes (no changes to daml.yaml file and no changes to any .daml file)
We later on figured out that this is because we have the -j flag on when doing daml build
daml build -j
As specified by the docs
The number of threads to run in parallel.
When -j is not passed, 1 thread is used.
If -j is passed, the number of threads defaults to the number of number of threads to N.
Note that the output is not deterministic for > 1 job.
Important and painful takeaway for me: packageId only remains the same if we have -j = 1 (or simply don’t add the flag in, default -j is 1) and there’s no changes in .daml files and daml.yaml file.
Hope this will help anyone that is scratching their head over the same issue.
Interesting find, thanks for posting the solution!
I would also recommend including package ID extraction as part of the build process. For example, the create-daml-app
and quickstart-java
we supply work like this:
- build daml dars
- generate TypeScript/Java code from the dars, including package ID
- compile hand-written TypeScript/Java code against that generated code, hence using the package ID that was just built
For cross-project dependencies, data-dependencies
are the best choice to preserve package ID stability.
Only adding this to say that there is a range of solutions to this issue, and different projects will find different ones to be appropriate.
Hi @Stephen,
Could you elaborate a bit on what guarantees data-dependencies
offer compared to dependencies
?
Thanks
The “cut the Gordian knot” way to preserve package ID is to use a distributed prebuilt binary. Can’t get multiple package IDs if you’re always using exactly one prebuilt package, after all.
data-dependencies
fix
- the SDK upgrade problem with this strategy – you can use deps built with older SDK versions in new projects
- the distribution problem – you don’t need an out-of-band dar distribution mechanism to fetch a data-dependency, you can use the ledger
- relatedly, the “lost library” problem – if upstream loses or has trouble reproducing a dar, it doesn’t matter, because if the templates/data types are in use, the correct dalfs must be on a relevant ledger