Dependency Management

Questions
1

Hi,

I I can’t seem to find a way to deploy my dar files like I would my other resources in a local or remote artifact repository. Is that feasible both in terms of deployment but also daml.yaml dependency setup?

4 Likes
2

DAR files are best treated as a single binary blob. You can then use any repository that can host binary files to store them, e.g., Artifactory or even something as simple as a GCP bucket.

We don’t currently provide any functionality for uploading to such repositories or referencing remote repositories in your daml.yaml. So you would instead rely on standard tooling for your repository for this and download your dependencies before you call daml build and then reference the locally downloaded DAR in your daml.yaml. Depending on your usecase, you can also check in the DARs of your dependencies with the usual caveats that apply to binary files in git.

2 Likes
3

Thanks

Is it somewhere on a roadmap?

1 Like
4

It’s currently not on our immediate roadmap, but rather on our backlog. My personal take is that there are really two types of dependencies that need better support:

  1. During initial development, one might want to organize the project into multiple packages. Eg I may want to have my tests, scripts, and triggers in a separate package to my contracts so that changing tests does not affect template identifiers. To make this slicker, we need multi-package projects or project dependencies, which make sure upstream changes trickle through.
  2. During maintenance and operation, one wants to depend on packages already running on a ledger. Here I find it preferable to think of the Ledger itself as the artifact repository. Otherwise you have to sync Ledger, Artifactory, and local library rather than just Ledger and local library. This is supported in embryonic form using the daml ledger fetch-dar command, which allows you to reference a package by package hash and get a dar file from the ledger, which contains that package.

What’s your use-case for this feature, and what do you think would be the minimal dependency management feature that would make your experience smoother?

4 Likes
5

Thanks a lot @bernhard! Not having this feature :
a) breaks my CI/CD setup that handles my artifacts (docker, npm, jar, etc…)
b) makes it more difficult for me to reference a dar file from another project
c) breaks the build models (java, kotlin, rust, javascript etc…) for no obvious rationale.

All I need is my usual cargo/gradle/maven/… dependency management, no more no less. I should not have to break basic development practices for daml.

1 Like
6

Disclaimer: I am not working on anything related to this and have no idea what current plans are regarding this. This is just an observer’s opinion.

I could imagine a Maven-like infrastructure for DAR files. Pure library DARs (i.e. with no template) would work just like any Java/Rust/… file. Templates are a bit of an issue, though, because they have to match the data you have in your persistent, production database, where every entry is signed by multiple participants. This makes DAML model upgrades a bit more complicated than upgrades in other languages.

I think this also makes the case for shared (template) code a lot weaker: it seems less likely you’ll be able to reuse common templates.

I can still see value in that, though. I can conceive of templates that would make sense, and I can imagine even upgrade templates being reusable to some extent.

Without going through the trouble of developing an alternative to Maven Central (there’s a lot of work in that), perhaps a lighter step in that direction would be to support more URL schemes in daml.yaml when specifying dependencies? Having the ability to specify a dependency as, say, a relative/absolute path (as now), an HTTPS URL, or a git URL would give users a lot of flexibility in setting up their own DAML code repositories without too much of an implementation cost on us.

1 Like
7

Thanks @Gary_Verhaegen, we can use maven to upload the dar but we cannot reference it in the daml.yaml file and that’s where the problem is…

1 Like
8

Right, sorry if I was not clear: this was more of a feature request to @bernhard than a solution for you.

I’m afraid at the moment the situation is as described by @cocreature, i.e. we don’t support any remote location for DAR dependencies.

What you can do is upload the DAR files to your repository of choice, possibly using Maven (or any other tool) on the “producer” side, and on the “consumer” side, just download them. That is, in your build script, rather than just

daml build

you’d have

wget https://your-maven-repo/path/to/dependency.dar
daml build

or something along those lines.

2 Likes
9

completely agreed – !!! Thanks a lot @Gary_Verhaegen

1 Like