Andreas Herrmann

> Are there any other attributes that would be desirable to specify per module? Plugins come to mind, as discussed in https://github.com/tweag/rules_haskell/pull/1566#discussion_r673414169 in the past. That said, the "abstract" approach...

@Radvendii > IIUC, the advantage of the explicit approach is that it is simpler to understand and implement, meaning (potentially) fewer bugs. Is that right? Is there anything else to...

I think the abstract interface is preferable. From a user's perspective it provides a higher level and more declarative interface: The user defines the module dependency graph, not the mechanics...

> My first try was making a recursive function, for every `haskell_module` target, the function would create first the actions to compile its dependencies, and then it would create the...

A `depset` seems like the best data structure and I'm not aware of a `depset` of `Target`s being a particular performance concern. As far as I know `depset` doesn't use...

> We have to flatten the transitive dependencies once per compile action for a module in order to produce the list of input interface files. This does look quadratic on...

> However, I'm failing to see the essential difference with the previous sketch. Your last sketch still flattens the transitive inputs once per action, only that it is deferred until...

> Should dependencies be inherited from libraries and binaries? `gazelle_haskell_modules` copies those into the dependencies of `haskell_module`, but maybe we should leave room to the user to tweak that manually...

With flakes available now switching to flakes to provide `nixpkgs` may be a better option.

@tshaynik Nice, that would be a good change. Beware that the are two layers to this. One is the Nix shell that provides Bazel, that should be reasonably straight forward,...