PackageId hash changes without Daml code change

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:

1. build daml dars
2. generate TypeScript/Java code from the dars, including package ID
3. 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.

Stephen:

For cross-project dependencies, data-dependencies are the best choice to preserve package ID stability.

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

1. the SDK upgrade problem with this strategy – you can use deps built with older SDK versions in new projects
2. the distribution problem – you don’t need an out-of-band dar distribution mechanism to fetch a data-dependency, you can use the ledger
3. 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