[toastal]

I don't know; that's why I'm asking. Maybe buildOpamPackage already does it? https://github.com/tweag/opam-nix#buildOpamProject There's a buildDunePackage in the same region of the docs that runs `dune build` but that to me implies that dune is not needed(?). I haven't read too much into the project yet. The example (https://github.com/tweag/opam-nix/blob/4bb1a4c372f639f44fc67...) would indicate that everything is configured from just the ${PROJECT}.opam file, but I don't have enough info on the toolchain to know if it's incremental per module or what... or if ocamlfind more complicated to work with than dune.

[ghostwriter]

It does run `dune build`, but the unit of persistence within Nix is defined as `buildDunePackage`, i.e. the Nix store will only know about the package rather than individual modules and a change in a single module will cause a cascading rebuild of the entire package to update the nix store.

[toastal]

There are tools out there for other languages that _can_ handle incremental & per-modules builds, such as purs-nix for PureScript, so if opam-nix doesn't now, I'm sure it will in the future as a lot of projects are asking for this feature.

[ghostwriter]

> what does dune actually offer me if I’m using Nix to manage dependencies already?

purs-nix is a good example that even if per-module compilation is made into derivations, the rest of the remaining heavy-lifting of constraints resolution is done by the external build tool. You can think of Nix as a dependency manager, but only with a huge caveat that it doesn't actually manage constraints that come with those dependencies, especially transitive ones.

[toastal]

That's a good read but I'm still unclear on dune vs. ocamlfind/ocamlopt. Is dune not using those under the covers like Nix could?