Two oh

[lucianojoublanc-da]

This incorporates #39 and also removes daml-ctl git submodule in favour of a data-depenency.

Just waiting for 2.0 release that fixes --target=dev.1; then we'll bump daml.yaml files to release.

[lucianojoublanc-da]

So we have a bit of a problem, which we'll also have in the finlib. The CI needs to know how to handle external dar dependencies.

I removed the git submodule I was using to build daml-ctl. But now the CI doesn't know how to build it. We have to make the dependency dar available somewhere (I am not checking into git) i.e. it has to have a stable path that the CI can download it from.

I'm tempted to just keep the submodule for the time being, as there are no other libraries (to my knowledge) using daml-ctl. Also worth asking colleagues how they are handling this. cc @bame-da

[lucianojoublanc-da]

We have to make the dependency dar available somewhere

Further discussion with @georg-da , we've decided to use github releases; this means we need to manually upload the *.dar, but it should provide a stable path that the CI can then refer to. Well do the same with daml-ctl.

[bame-da]

@lucianojoublanc-da what's stopping you in CI from checking out another repo and building it?

[lucianojoublanc-da]

what's stopping you in CI from checking out another repo and building it?

I suppose this is what we were previously doing, albeit via a submodule; in that case the dependency is explicit in the codebase (the submodule points to a specific commit in the dependency). We wanted to avoid this.

I guess the answer to your question is CI time, and complexity of CI configuration. In this particular case, it's not too much of an issue, but say we have a customer project that depends on finlib, which depends on contingent-claims, which depends on daml-ctl. That means you're going to have to build three sub-projects in your CI ...