How would you provide incremental per-module compilation for your Nix derivation of the app?

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.

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.

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.

> 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.

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?

I see nix as a partial build system. It’s a more evolved makefile that will call bash scripts or other build systems to really build things in different languages. For OCaml you’ll need dune to build your projects, and that’s what nix will end up calling after setting the dependencies for you.

While you can _build_ OCaml projects without Dune (although I wouldn't want to do that), _editing_ OCaml code I wouldn't recommend, as the OCaml-LSP depends on dune. If you're an Emacs user: Merlin AFAIK doesn't need dune.

I see. I wasn't aware that Nix was a build system and probably should have investigated a bit more before responding. Truthfully I don't use OCaml professionally but just in a hobby capacity. I believe you could roll your own using Make but the compiler invocations (which you can get dune to spit out if you want) become more complex over time the more features you add like PPXs, or `ctypes`, and unit testing, the more time you will save by using dune. tl;dr running ocamlopt directly works but will become cumbersome the bigger the project becomes

That’s still great feedback though—especially when you mention PPX support which is pretty common.

While it might be possible, it's not very practical.

The original Nix thesis [0] talks about using Nix as a low-level build system in Chapter 10.1. And the author of opam-nix* has made an attempt to use Nix as a build system [1]. However, dune is a complicated bit of software that's not easy to replicate, and Nix isn't particularly well suited to the task.

[0] https://edolstra.github.io/pubs/phd-thesis.pdf

[1] https://gitlab.com/balsoft/tumbleweed

*Which is essentially functionality to use Nix as a dependency manger with opam-repository.