Managing package dependencies with Bazel

Questions
6

This is a common problem when using Bazel with off-the shelf, language-specific build systems (I’d count daml build as one in this case). If you hand over control fully to Bazel, things like IDE integrations break which is obviously annoying (this is the approach taken by rules_daml @bernhard pointed you to above). If you don’t, then you have to keep things in sync. In your example that means manually updating libs/B.dar when it changes (or try to symlink it from the bazel dir but that gets increasingly hard once you take different operating systems, optimization levels, … into account all of which influence the directory bazel uses).

There are a few options to get out of this conundrum that different languages have chosen:

  1. Instead of pointing your IDE directly at your underlying tool (damlc in this case) you point it at some wrapper script which queries Bazel to build and locate depedencies and then invokes the underlying tool with some extra flags to make it find dependencies. This is the approach taken by Haskell tooling for example and Scala also does something along those lines.
    For Daml, this would mean that you have a daml.yaml with an empty list of data-dependencies/dependencies. You then need your Bazel build setup to produce package databases, e.g., by wrapping daml damlc init or maybe even go lower-level and construct them manually (unfortunately no docs on this atm). Finally, your wrapper script would find the location of those package databases and then invoke daml damlc ide --package-db=… --package-db= … --package=… --package=… and your IDE should find dependencies. This is probably the approach I’d recommend but it is a fair amount of effort.
  2. Another option taken by rules_nodejs is to have Bazel step out of its build root and mess around in the actual source tree, e.g., modify node_modules. In this case, this could mean modifying daml.yaml to point to the location of the dependencies. That requires in some sense less effort since you don’t need the wrapper script but it also gives up on Bazel managing your stuff cleanly and you get back to the good old days where rm -rf node_modules solves your problem (or whatever the equivalent of that in Daml is :wink: )
  3. Lastly, you could also imagine some kind of native support in the compiler to make the location of source files and dependencies configurable. I’m not really aware of any language that has proper support for this atm that works well with Bazel but it has at least been discussed for Go in the context of Expose generated Go files to editors and IDEs · Issue #512 · bazelbuild/rules_go · GitHub.

So unfortunately, while I think making 1 work is definitely feasible, the current situation is not great. I’ve opened Improve UX when compiling Daml code in Bazel or other build systems · Issue #8767 · digital-asset/daml · GitHub to track this on our side and we’ll see what we can do to make the UX here a bit better.

1 Like