digital-asset / daml

The Daml smart contract language
https://www.digitalasset.com/developers
797 stars 199 forks source link

Conflicting package ids for `daml-script` when used across LF versions #15654

Open akrmn opened 1 year ago

akrmn commented 1 year ago

Given a project dd which targets LF version x (e.g. 1.14) and depends on daml-script, and a project main which targets LF version y such that y > x (e.g. 1.15), also depends on daml-script and has dd as a data-dependency, attempting to build main fails with an error like

Transitive dependencies with same unit id but conflicting package ids: daml-script-2.4.0 [HASH1,HASH2]

To reproduce, place dd/daml.yaml, dd/DD.daml, main/daml.yaml and main/Main.daml (see Files) in the same directory (keeping the structure) and run

DAML_PROJECT=dd daml build && DAML_PROJECT=main daml build

It will fail with

Transitive dependencies with same unit id but conflicting package ids: 
  daml-script-2.4.0
    [ 7efc35e331d20e12e1fcd3f58cbd026187ee79a16bc2bfcc5daeb81808bd5286
    , b07797b054870e3b4e527efb44610e40c8420ce7d8876925779b99ecbd89f156
    ]

Files

# dd/daml.yaml
sdk-version: 2.4.0
build-options: [--target=1.14]
name: dd
source: DD.daml
version: 0.0.1
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script
-- dd/DD.daml
module DD where

import Daml.Script qualified

newtype Script a = Script (Daml.Script.Script a)
# main/daml.yaml
sdk-version: 2.4.0
build-options: [--target=1.15]
name: main
source: Main.daml
version: 0.0.1
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script
data-dependencies:
  - ../dd/.daml/dist/dd-0.0.1.dar
-- main/Main.daml
module Main where

import DD qualified
import Daml.Script qualified

ddscript : DD.Script ()
ddscript = DD.Script (pure ())

script : Script ()
script = pure ()
akrmn commented 1 year ago

This is much trickier than I thought. The problem is that the package id is used in quite a few places for slightly different purposes, so adding the lf version in one place breaks others, and it all feels really hacky. I think a proper solution would need to add proper handling for SDK packages so that they can be addressed by a package id without an lf version while internally having a fully specified package id.