Make the project build using the committed lock dir

[Leonidas-from-XIV]

Since there is a lock.dir in the project and Dune can build the project with package management, this changes the Dockerfile to use dune pkg for building it.

Currently it is experiencing some kind of issue:

0.213 File "dune.lock/lock.dune", line 1, characters 0-0:                                                                                                                                                                                                                       
0.213 Error: The lock dir is not sync with your dune-project
0.213 Hint: run dune pkg lock

I do not experience the issue outside the Docker container and it works when using autolocking so there seems to be some kind of issue with the lock directory.

[Leonidas-from-XIV]

While working on this I ran into a bit of a painful situation where the dependencies on my machine don't match the dependencies in the Docker container, so I've revived this PR.

This should make sure that the dependencies match. This will allow us to drop the usage of OPAM from this repo.

[Alizter]

Why can't we download the binary directly? Building dune here seems like a waste of time?

[Leonidas-from-XIV]

@Alizter The issue is that this is the project that creates the binaries, thus downloading the binary would create a circular dependency. I could install a Dune from the system (Alpine 3.23 ships with 3.20.2 which is not too old), which would avoid this issue?

[Alizter]

I suppose the better solution would be to have dedicated docker images with the released version of dune in them, but that seems more trouble than its worth. I think using an older system version of dune seems fine.

[Leonidas-from-XIV]

As discussed with @Alizter and @Sudha247 the issue at the moment is that Alpine ships 3.20.1 but dune pkg lock will create a lock file that features dune-configurator.3.21 (at the moment) which requires dune-lang 3.21. Thus the Dune in Alpine can't build it as it has no support for dune-lang 3.21.

This is a problem in general that the Dune solver might pick versions of packages that don't work with the Dune version at hand, I will create a ticket in Dune about this.

I've worked around this for now by forcing the lock dir to use dune-configurator < 3.21.

[shonfeder]

the better solution would be to have dedicated docker images with the released version of dune in them

We have a docker container with dune build thanks to earlier work from Sudha: https://github.com/ocaml/dune/pkgs/container/dune

Would using this, with the latest tag, perhaps solve most of the problems discussed here?

[shonfeder]

Could you add a comment noting why this is necessary?

[Alizter]

@Leonidas-from-XIV mentioned that the dependency hash was being out of sync in the docker container and he had yet to determine the cause. I believe this line was an attempt at removing it. I'm not particularly sure what caused this issue yet.

[Leonidas-from-XIV]

That's exactly right. If I leave it out I get the error that's mentioned in the opening message of the PR.

I plan to create a repro case for this issue (which seems like a Dune bug) which should help debug this issue in a separate repo.

[shonfeder]

Ok! Sounds like this is still under investigation. If ends up needing to be in the final state of the PR, I just request it be with a comment explaining why it is needed.

[shonfeder]

That makes it clear! Linking to the issue tracking this bug will make it easier to know when this workaround can be removed.

[shonfeder]

That makes it clear! Linking to the issue tracking this bug will make it easier to know when this workaround can be removed.