[ffarall]

Follow-up to #311 (see conversation). damlc from SDK 3.6 accepts map entries in dependencies and data-dependencies, so the structured git form dropped in that PR can stay in daml.yaml instead of being flattened to a git: one-liner.

Summary

• A git DAR may be declared as a mapping. url, ref, and path name a file in the repository. release and asset name a GitHub release asset. main-package-id may sit beside git. Any other key is rejected.
• Install and update still fetch and pin. A mapping stays a mapping: pinning rewrites ref to the commit SHA. One-liners are unchanged.

sdk-version: 3.6.0
dependencies:
  - git:
      url: github.com/org/repo
      ref: main
      path: packages/foo.dar
    main-package-id: <package-id>
data-dependencies:
  - git:
      url: github.com/org/repo
      release: v1.0.0
      asset: foo.dar

⚠️ SDK 3.6 gate

This is the choice most likely to need discussion.

The idea is to give the user a clearer error when they're trying to use a structured git dependency on an older SDK with an older damlc that does not support it.

In this PR's code, dpm refuses to launch an SDK command when the package contains a structured git dependency and the SDK that command would run is older than 3.6. The constraint is >= 3.6.0-0, so 3.6.0 and 3.6 snapshots pass, and 3.5 and earlier do not. The version checked is the one injected as DPM_SDK_VERSION: that environment variable if set, otherwise the package sdk-version, otherwise multi-package.yaml. A file that says 3.6.0 is still rejected when the command would run 3.5. An empty version is rejected too. The error tells the user to use a git: one-liner.

The gate is deliberately not part of reading daml.yaml. dpm install package, dpm update, and dpm resolve still fetch, pin, and resolve a structured entry on an older SDK. The failure is reserved for the moment dpm is about to hand the file to damlc, which is what cannot read the mapping.

Two limits follow from that placement:

• The check runs for every SDK command started inside a package, including commands that never read dependencies.
• It does not run for built-in dpm commands, for a project that selects its tools with components:, or for a multi-package command started from the project root rather than from a package directory. In those cases damlc reports the mapping itself.

The git: one-liner is not subject to this check.

[dasormeter]

@ffarall can you rebase your PR? -- will review and merge today if all looks good