PackageID creation

I found that the same daml project created different package ID under Linux and Windows. Is this observation correct? Anyone knows what kind of changes affect the package ID? Does OS or machine play a role in package id creation?

The package identifier is “just” a hash of the compiler output. To the best of my knowledge, as long as you use the same compiler version to compile the same exact Daml code with the same Daml-LF target version you should obtain the same package identifier.

Hi @Frankie,

I’m not very familiar with that area myself, so can’t comment on whether this is expected behaviour, but I can confirm that I see the same thing you do. Here’s a minimal repro.

On macOS:

$ DAML_SDK_VERSION=1.14.0 daml new t; cd t; daml build; daml damlc inspect-dar .daml/dist/t-0.0.1.dar | tail -1 | awk '{print $2}'
Created a new project in "t" based on the template "skeleton".
Compiling t to a DAR.
Created .daml/dist/t-0.0.1.dar
"95a4f9eac14568ba8d688c8de68c0983307a17fde5b67707745216e3a14e304a"

On Windows:

$ DAML_SDK_VERSION=1.14.0 daml new t; cd t; daml build; daml damlc inspect-dar .daml/dist/t-0.0.1.dar | tail -1 | awk '{print $2}'
Created a new project in "t" based on the template "skeleton".
Compiling t to a DAR.
Created .daml\dist\t-0.0.1.dar
"726ddf031309b2c6ad0bd18418a9526dc84efcc2919a997262cb68474d273a32"

Thanks for the repro! I hope my initial assumption was wrong then.

We’ve been doing some digging. The short version seems to be:

• This is a bug. We expect the package ID to be dependent only on the source files and SDK version, and not on the platform, as @stefanobaghino-da mentioned.
• This bug has pretty much always been there (at least since 1.0.0).
• Fortunately this is the type of bug we can fix without breaking backwards compatibility as package IDs are supposed to depend on SDK version anyway.
• The root of the issue seems to be embedded paths in the DAR files using / on macOS/Linux and \ on Windows.
• Fixing this may not be trivial as these paths need to be passed to other tools that may break if we’re not using the platform-specific path separator.
• Fixing this is not currently considered high-priority: while unexpected, this is not causing any issue that we’re aware of.

In case you’re interested, work on this will be tracked using this GitHub issue.

@Frankie I just wanted to add, good job spotting this bug and thanks for reporting.

no problem at all.

Awesome @Frankie, thanks for spotting this!!

Just to go a bit further on this one. What kind of changes in daml.yaml file will affect the package id? e.g. add an unused dependency? update parties? update scenario-service?

First, let me add a small clarification to what @Gary_Verhaegen said above:

damlc provides deterministic compilation but only in single-threaded mode, non-incremental mode (which is the default). If you start doing parallel and/or incremental compilation build outputs become non-deterministic.

As for your question, dependencies used or unused can effect the output. Other changes like parties, scenario service config, ledger deployment config, … do not affect compilation at all.

The packageId also depends on the version of the compiler (sdk-version in daml.yaml) as well as the target LF version.