Clarify and document the status of opam packages, and publish them in the opam repository

[jhjourdan]

How should opam be used to install unison?

Looking at the sources, it seems like the opam file is written to provide two packages at once: unison and unison-gui. Could this be documented somewhere?

If the purpose of the unison package is to drop the dependency to lablgtk, then it should not mention it as a dependency.

Is there a reason to have two packages when opam features "optional dependencies", which are precisely designed to only enable a feature (e.g., a GUI) if the corresponding dependencies are enabled? Could this be documented?

The most recent unison package in the opam repository is 2.52.0. It does not contain any version of the unison-gui package. Would it be possible to have a more recent version (2.53), both with and without the GUI?

[jhjourdan]

Yet another complain (sorry...): if the same opam file is used for two different packages, then it should be called opam and not unison.opam: otherwise, opam does not find it for the unison-gui package.

Also, it is weird that when the GUI is enabled, the executable produced by the Makefile is unison, while it is unison-gui when using dune.

[gdt]

Basically unison.opam is not really maintained, and the people maintaining unison do not really understand opam. unison's build system is simply make. Arguably the opam file should be hosted in the opam world.

[gdt]

See also #824

[jhjourdan]

I don't understand, then: why is there a parallel dune build system for opam packages? Does any of the maintainer use dune?

I could volunteer becoming the opam package maintainer, but then I will choose the solution that requires the least maintenance effort: I would drop all the dune build system, and have a simple opam file that call make. Sure, this is perhpas a bit sad for e.g., parallelization, but at least we will have a working opam package...

Cc @olafhering, @kit-ty-kate, @ejgallego, @liyishuai, who seem to be involved in opam/dune in unison.

[olafhering]

There is indeed a life outside of opam.
If I were in charge, all and everything would be built with dune, simply because it gets everything right (AFAICT).

Regarding unison itself, there is enough of dune support in unison.git to be able to build binaries with dune instead of make. However, some pieces are still missing, like generating the documentation. This is just a matter of man power to get this sorted out.

In the end it is up to the maintainers of opam-repository (or whoever feels to be in charge) to provide proper *.opam files to build unison with a text ui and with a graphical ui. It just needs a slight adjustment to the existing dune-project file to generate proper *.opam files, which could then be commited to the opam-repository. There is a PR open since a while.

[jhjourdan]

Writting opam files is not the responsibility of the maintainers of opam-repository (there are way to many packages to maintain for them), but it is the responsibility of the individual package maintainers.

I volunteer becoming such a package maintainer, but then the opam file I would write would use the official build system used by the majority of the maintainers: the main Makefile.

[gdt]

There are a lot of issues here and they don't sort neatly into things that the bug tracker is for. I would like to discuss it with everyone on unison-hackers@, and will try to send a note there in the next day or two.

[ejgallego]

The reason I added some dune support is actually because the Makefile system was broken in newer OCamls, moreover, the make-based build system lacked support for many features including good editor / merlin integration.

Moreover the make-based system doesn't support incremental build properly (so you need to clean at every step at git bisect, etc...) the list is long. It is very uncommon these days for an OCaml project to require less maintenance effort by using make.

IMHO the key point is what OS / architectures unison wants to support. If that set is covered by dune, there are few resons to keep using make.

[liyishuai]

I could volunteer becoming the opam package maintainer, but then I will choose the solution that requires the least maintenance effort: I would drop all the dune build system, and have a simple opam file that call make. Sure, this is perhpas a bit sad for e.g., parallelization, but at least we will have a working opam package...

Does #671 fix the opam files for you?

[liyishuai]

There are a lot of issues here and they don't sort neatly into things that the bug tracker is for. I would like to discuss it with everyone on unison-hackers@, and will try to send a note there in the next day or two.

The latest email on my side was Sept 25. Never have I received responses to my June 24 thread regarding #671. Does the mailing list broadcast every message to everyone?

[jhjourdan]

Does #671 fix the opam files for you?

Yes and no.

Yes, these new opam file should make me able to install unison with the GUI via opam (provided they are not bogus, I have not tested them, but I guess you did).

But it feels weird to have two different packages and executables for the same piece of software (unison), configured with and without the GUI. Any other installation method for unison will have the same executable names for the version with and without the GUI (which UI is used is the matter of a command-line option). Also, it is rather easy on the OPAM side to specify that the package can be installed with or without lablgtk, thanks to optional dependencies. I admit this is a minor issue, and I can live with that (provided it is properly documented somewhere).

[gdt]

The latest email on my side was Sept 25. Never have I received responses to my June 24 thread regarding #671. Does the mailing list broadcast every message to everyone?

Yes, and I got your message. The problem from my side is that I don't fully understand all the issues and there seem to be diverging opinions. I will send out another message on hackers summarizing my improved understanding of where we are. I do not want to have open-ended or policy-type discussions on github; the project was grounded in mailinglists before github existed.

[gdt]

Please see https://lists.seas.upenn.edu/pipermail/unison-hackers/2022-November/002061.html and followup on the list.