Dune can create a “lock directory” containing a package dependency solution for a project. The command to generate the lock directory is dune pkg lock, and the dependency solution will be specific to the machine (OS/arch/distro/etc) where that command was run; if you run dune pkg lock on a linux machine, the resulting lock directory will not work on a mac. The lock directory is named “dune.lock” by default. The directory contains one text file for each package in the project’s dependency closure, with copies of some of the fields from the package’s opam file (converted into dune sexps). If a project has a lock directory, it can be built along with all its dependencies, without an installation of opam present.
The context for this post is that the dune developers are considering what work needs to be done before we can start promoting the widespread use of dune package management as an alternative to opam.
Before encouraging the widespread use of dune package management, I’d like to avoid the situation where a developer generates a lock directory for a project and checks it into version control, and then a second developer finds they are unable to build the project because they’re using a different type of computer to the first developer, and the project’s lock directory is specific to the first developer’s computer.
I claim that naming the lock directory “dune.lock” by default will encourage developers to check it in, as that is the convention in other ecosystems where lockfiles are similarly named (at least for applications). The solution proposed in this issue is to change the default name to “.dune.lock” which will hopefully at least give developers pause before checking in their lockdirs. The issue proposes a workflow similar to local opam switches, where dune is used to install a project’s dependencies into a per-project sandbox.
There is an argument for checking in lockdirs despite them being specific to one type of computer, which is that it allows people using identical computers to one another to guarantee reproducible builds. This might be useful in corporate settings where the company can guarantee that all developers will be using identical machines, or for solo devs who only have one computer.
Dune does support a project having multiple different lockdirs, specific to different OS/arch/distro/version/etc combinations, but I don’t think we should encourage the use of this feature as there could be potentially many lockdirs for a project and they could drift out of sync.
Dune also has a feature where the specific revision of the opam repository that was used to solve a project’s dependencies can be recorded in the dune-workspace file. This alone acts somewhat like a lockfile, and can be safely checked into version control and used on different machines. In this case, dune running on two different machines with the same OS, architecture, etc. will produce the same package solution. Solving a project’s dependencies can take several 10s of seconds in the worst case, and the lockdir is effectively a cache of the result of this process.
I’m interested to hear what other ocaml users think about dune lock directories. If dune created a lock directory for your project named “dune.lock” would you be likely to assume it to be a general-purpose lock directory and check it into the project? Would naming it “.dune.lock” instead make you less likely to check it in? Given that lockdirs are not cross-platform, under what circumstances would you still check one into version control anyway?