Dealing with standard library module name collisions

Questions
, , ,
1

We have a project which has a data dependency dar referenced. While daml build and js bindings are created fine it will not generate the java bindings due to a duplicate module issue within the standard library. Perhaps we have applied it wrong but module-prefixes does not seem to make a difference and the error still occurs.

data-dependencies:

  • library-name-1.2.1.dar
    module-prefixes:
    library-name: library-name

Command run:

daml codegen java ./.daml/dist/project-0.0.1.dar=com.namespace.projectname–verbosity 4 --output-directory=java-codegen/src/main/java

Excerpt:

Error generating code: Duplicate module com.namespace.DA.Next.Map found in multiple packages 9264d7a02cdbcf483d3f60ff0e351b6ccc7a803e8a3b1f96e6beeb31dd390437, 3b85572e240440a547a727b78eff8c13e00ad8a2e579146037dad172365dcb25. To resolve the conflict rename the modules in one of the packages via module-prefixes.

daml-helper: Received ExitFailure 201 when running

2

What version of the SDK are you using?

3

SDK is 1.18 the dar we are using as a data dependency was built using 1.3

4

Can you share your full daml.yaml enclosed in a codeblock? It’s not clear to me from your first post if the formatting is right or not.

1 Like
5

Original daml.yaml

sdk-version: 1.18.0
name: project-name
source: src/main/daml
version: 1.0.0
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script
sandbox-options:
  - --wall-clock-time
data-dependencies:
  - data-dependencies/library-name-2.0.0.dar
build-options:
  - --ghc-option=-Wno-deprecations

Tried adding the below in different ways (full name, include version, full path, no hyphen, etc)

module-prefixes:
  library-name: l-n
6

Can you share the final daml.yaml rather than the original one? I’m particularly interested where exactly you placed the module-prefixes line.

7 
sdk-version: 1.18.0
name: project-name
source: src/main/daml
version: 1.0.0
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script
sandbox-options:
  - --wall-clock-time
data-dependencies:
  - data-dependencies/library-name-2.0.0.dar
module-prefixes:
  library-name: ln
build-options:
  - --ghc-option=-Wno-deprecations

Have also tried the flags as part of build options

8

The issue is that you are renaming the wrong package. If you look at the error message, you can see the package id it is complaining about. You need to use packagename-packageversion of that package as the key in module-prefixes. One option for figuring that out is to use daml damlc inspect-dar, e.g. as follows (replace the path to the DAR):

$ damlc inspect-dar --json .daml/dist/b-0.0.1.dar | jq '.packages."3b85572e240440a547a727b78eff8c13e00ad8a2e579146037dad172365dcb25"'
{
  "path": "b-0.0.1-939b95c20df2dbf6dbe4852acb2b595514e29020af13f6697ce729bfcae0c5ca/daml-stdlib-3b85572e240440a547a727b78eff8c13e00ad8a2e579146037dad172365dcb25-3b85572e240440a547a727b78eff8c13e00ad8a2e579146037dad172365dcb25.dalf",
  "name": "daml-stdlib",
  "version": "1.3.0"
}

So you see the name and version there meaning, you would need an entry of the form:

module-prefixes:
  daml-stdlib-1.3.0: OldStdlib

Now unfortunately, there is a bug where package names with dashes in them are not parsed properly. I fixed that in Fix parsing of java codegen module prefixes by cocreature · Pull Request #12977 · digital-asset/daml · GitHub but that doesn’t help you on 1.18.0.

Unfortunately, I failed to find a reasonable workaround on 1.18.0.

1 Like
9

Thanks. With that fix in place, in a multi dependency world where each may have been built with different versions of the SDK would we need to prefix each and every one of their standard libs?

How would this behave when we have a nested dependency tree say - A > B > C and B > D and we reference C and D in our dars data-dependencies (again where some may have been built in different SDK versions)

10

If your DARs contains multiple versions of daml-stdlib you might need to rename multiple ones yes. Keep in mind thought that you should generally structure upgrades such that you don’t keep references to old packages forever. Take a look at the upgrading documentation for an example of how to avoid a direct dependency from your new models on your old models.

As for nested dependencies, we deduplicate packages across DARs. So B will only be there once and not collide with itself (at least it shouldn’t, see [BUG] Java Codegen collision module name collision check is missing deduplication · Issue #11457 · digital-asset/daml · GitHub for a bug that may affect you).

11

Is there an ETA on a fix for this. Getting the exact same GHC.Stack.Types duplicate module error

12

It’s in our working queue but there’s no ETA currently.

1 Like
13

Can the priority of this be looked into or a workaround provided. Say we’re on version 2.3.2 and a 3rd party library was built using a pervious version, we effectively cant use it (module-prefixes doesn’t help either).
In our case its purely for data types.

14

A workaround, if you have access to the 3rd party library source code, is to build it against SDK 2.3.2. We’ll raise the priority of this and work on it in the coming weeks.