Julow
commented
1 year ago I completely agree! Ideally, every tools would expose their library into a separate package. (issue on ocamlformat: https://github.com/ocaml-ppx/ocamlformat/issues/2190)
I think we should move on with this idea. Fixing (generally) https://github.com/tarides/ocaml-platform-installer/issues/126 is more important than supporting the rare workflows of depending on ocamlformat's library, especially if we can change that.
Also, with the new --with-dev-setup, our workaround will need to be improved so removing the cruft now won't hurt future development.
panglesd
The fact that some platform tools are not pure binaries, as is they include libraries, can be problematic: the version installed by the installer only contains binaries, so it differs from the complete version.
Due to this, we did not want to replace "original" packages: we name them differently (so that packages that depend on them install the true version) and never replace a true version by a platform one.
This will play terrible with the new
with-dev-toolsof opam 2.2 (https://github.com/ocaml/opam/issues/4959), and the "never replacing original package" has already given rise to #126.Dune is considered a pure binary so it does not suffer from this problem (that would be a big problem since every package depending on it (almost all) would reinstall it). On the other hand, the following tools are currently considered "missing the libraries" in the installer:
dune-release. I don't know how much library is included in that package but no latest version of a package depend on it.merlin. This package has now a separate opam package for its library.The only "latest" package that depend on the merlin package are gopcaml-mode and gopcaml-mode-merlin, two emacs packages written in ocaml. However, I think gopcaml-mode is superseded by the gopcaml-mode-merlin, whose latest version depends on bothmerlinandmerlin-lib. I suspect the latest version of gopcaml-mode-merlin would work with the platform-installed merlin.ocaml-lsp-server. No "latest" package depend on it (and I don't think anything should)odoc. Already, virtually any package depend on itwith-doc. I don't know if any package use it as a library...ocamlformat. Lots of packages depend on it viawith-test. Some of them depend on without constraints, but I think they actually only need the binary (fromager) or do not need it at all. Some people have expressed the need to have the library available, and it has been granted (in the same package unfortunately).I tend to think that we could consider all tools as "pure binaries", name them so that they can work as dependencies, and separate (or hide) libraries in another package.
(if we do this, then we can merge #127 without further hesitation!)