I’m happy to announce the release of a new version of opam-monorepo, a tool to assemble monorepos of your projects dependencies to compile them at once with dune, mainly used by Mirage to allow for easy cross-compilation.
Apart from some minor quality of life changes, opam-monorepo is now compatible with opam 2.6.0(and remains compatible with older versions), and benefits from all of its upstream improvements.
When using opam >= 2.6.0 and an older version of opam-monorepo, you might see errors like "No known implementations at all" when locking dependencies, in particular if the package has not been rebuilt. In that case, just upgrade opam-monorepo!
I find one thing very useful with opam monorepo: you can browse the source code across all ocaml libraries in your project with ocaml-lsp-server in a more reliable way.
There is nothing special you need to do. Build your switch with opam monorepo, install ocaml-lsp-server and you are good to go.
This approach is great when you want to understand even the source code of your project dependencies.
I don’t think this ability is spoken about enough.
Does it support optional dependencies, i.e. libraries in the monorepo that should only be compiled under certain circumstances (OS, available depext etc..)?
Build your switch with opam monorepo, install ocaml-lsp-server and you are good to go.
I must point out that instead of doing opam install ocaml-lsp-server it is probably better to just put a previously compiled ocamllsp in your $PATH. The reason is that opam install of arbitrary packages does not interact well once opam monorepo is up and working in a project.
Another caveat for those who are new to monorepo: opam monorepo requires each project package dependency to be buildable using dune. Since some packages don’t do that you need an opam overlay repository so those packages build with dune (opam monorepo will tell you how to add this overlay repository). It is not pretty but it does work.
I’ve made it sound a bit complicated. It’s really not. Try it out for the joy of goto definition into your project dependencies some time.
go-to-definition seems to work fine without opam monorepo, at least from my code into the dependency. I assume the benefit of a build setup like this is that it would also continue to work once inside those dependencies, if I wanted to jump “further down”?
Sure, though there are some subtleties about how it’s doing it, it a solver similarly to opam when locking dependencies (and that should take into consideration OS, etc.) and what you get is a monorepo with normal dune rules (including conditional compilation etc.)
Hi! Have you considered not vendoring the opam libraries? Then opam ci can catch when changes in opam no longer works with opam-monorepo, and otherwise users can easily upgrade the opam libraries used by opam-monorepo.