Upstreaming handwritten v/s *2nix-generated derivation (OCaml, opam2nix)

Development
1

What is the community’s preference in general – handwritten packages over derivation generated from a *2nix tool, or vice versa? Would auto-generated derivations be accepted into nixpkgs?

My context is to build OCaml packages. The options are buildDunePackage and opam2nix which uses buildDunePackage. While the latter’s documentation is sparse, after jumping through a few hoops, I was able to use it to build packages successfully.

Using opam2nix has been a breeze (with the caveat that I simply may not have encountered any nuanced problems yet). But I also wish to contribute these packages to upstream. Would anyone be willing to guide me whether such a generated derivation is fit to be accepted upstream? dream is a moderately complex example. opam2nix generates a single opam-selection.nix for an opam package, which describes the package itself, along with all its dependencies.

A few issues which might come up with opam2nix could be:

  • sharing dependencies with other packages. Stealing a quote from Re-using nixpkgs derivations for different package versions - #2 by SergeK :

    In particular, if there are two python packages that both depend on pytorch=1.6.0 (let’s assume hey are also locked to exact same revisions), I am not sure if, with poetry2nix or mach-nix , that huge pytorch binary distribution would be re-used between them. My expectation instead is that poetry2nix would produce two derivations, each with its own copy of pytorch . I’m still yet to check it.

  • cross-compilation

  • handling external dependencies (not in opam)

2

Glad you like opam2nix! One issue is that opam2nix itself isn’t in nixpkgs. I don’t really fancy taking on that effort, because I want the source of truth to be the opam2nix repository, I don’t want to maintain two parallel sets of nix expressions. I’m hoping that with flakes, it’ll be easy to use opam2nix “as-is” without having to duplicate the nix expressions in nixpkgs.

As for the reuse, it should work. At least, I designed it that way. If your solve happens to use the same package + version and all the same transitive dependencies, it should produce exactly the same derivation. I don’t know how often in practice that actually matches, because lots of solve differences (especially optional deps) will cause a mismatch.

1 Like
3

Hmm. I wish to keep nixpkgs to be the final source of truth for ocaml packages. But I understand your perspective. With a busy life, there is no point in taking in extra burden which you never intend to utilize.

Thank you for responding anyway! I will keep an eye on the development around opam2nix.

1 Like