Portable External Dependencies for Dune Package Management

Thanks for writing up your goals. For what it is worth, I’d like to point out that opam swtich export files (see opam/src/format/opamFile.mli at 2.3.0 · ocaml/opam · GitHub, or the “opam switch” manpage, look for import and export subcommands) fulfill the properties – especially those with --full and --freeze (options available since opam 2.1.0):

  • the file includes the build instructions, and source links, etc. for every used opam file;
  • you can use opam switch import <file> and won’t use the solver;
  • you can distribute these files, users/clients don’t need any opam repository to be present.

Since this is a dump of your opam installed switch, you may not get the platform-portability that this topic is about. But I think the file format and tooling is sufficiently ready and can be used as an interchange file format – so maybe “dune package management lock files” could be converted to these switch-export files.

In case you’re curious, here’s one of these switch export files.. FWIW, we use them since years for our reproducible build infrastructure, and for rebuilding packages (see https://builds.robur.coop in case you’re curious). Here, both --full (to embed potential extra-files/patches (no longer present in the main opam-repository)), and --freeze (to point to a specific git commit in case you’ve git-pinned packages) are used (and are necessary for reproducing the build).

I understand the term reproducible can be defined in various ways, I stick to the definition of https://reproducible-builds.org/ (bit-wise identical output). We developed orb to conduct these builds and rebuilds.

By no means I want to argue for or against something, I only want to emphasize that the @avsm mentioned interchange file format may already exist since a couple of years; and it may be worth to use this more.

6 Likes