Thanks very much for looking into this @ivg and @bobot! Just one clarification: rather than wrapping existing packages in nix (which is complex and adds multiple layers of indirection), I was thinking about this scheme:
- build a duniverse of the set of opam packages you want to publish in nix.
- Check that it all builds using
dune buildfrom the toplevel directory. - Now we add a build target to dune that will generate
<name>.nixpackages based on the fine-grained build information available to dune. These should not require opam to install at all, since nix replaces opam here as the coordination mechanism for ensuring that they are compiled and installed into the system.
Dune 1.10 has support for package metadata in dune-project, so the only missing metadata that nix would need here is the depext information, which I would also like to add into dune to aid configurator probing.
We primarily just need the runes to know how to drive Nix in order to generate the Dockerfiles:
- https://github.com/avsm/ocaml-dockerfile/blob/master/src-opam/dockerfile_linux.mli for the Linux setup for apt/rpm/apk
- https://github.com/avsm/ocaml-dockerfile/blob/master/src-opam/dockerfile_distro.mli has all the distro information (how is nix versioned?)
- ocaml-dockerfile/src-opam/dockerfile_opam.ml at master · ocurrent/ocaml-dockerfile · GitHub has the logic to hook this together to generate an opam container, from which we then build all the ocaml containers.
I know nothing about Nix, so even an issue on there with instructions would be a good start towards getting Nix/OCaml containers being built regularly. It definitely seems like the next best target we should aim for in our CI.