Re: troubleshooting problems with opam-monorepo

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

With the hope some opam-monorepo maintainer will read that and have some 
time, I just opened https://github.com/tarides/opam-monorepo/pull/407 
which puts "ocaml-compiler" into the set of "do not check for dune 
compatibility".
I'm afraid I don't know why there's now ocaml-base-compiler 5.3.0, 
ocaml-variants 5.3.0, ocaml 5.3.0, and ocaml-compiler 5.3.0.

Hannes

On 10/02/2025 11:12, Hannes Mehnert wrote:
> Hi,
>
> On 22/01/2025 18:11, Mindy Preston wrote:
> > Over the past few months, I have occasionally attempted to build some 
> > MirageOS projects but very frequently I encounter some time-consuming 
> > or work-halting problem with opam-monorepo, often a problem which 
> > seems non-deterministic. I have a few questions:
> > (1) is this brittle for other people? Perhaps there’s something about 
> > the environments where I’ve tried this (arch linux on aarch64, ubuntu 
> > and a close cousin on x86_64, recent opam, vanilla compiler) that’s 
> > problem-prone?  Is it possible that build steps involving 
> > opam-monorepo might cause inconsistent state if interrupted before 
> > completing, which is something I do all the time?
> It is brittle for me as well, over the years I opened various issues and 
> there's not much opam-monorepo activity unfortunately.
> The latest issue I encounter is 
> https://github.com/tarides/opam-monorepo/issues/406 -- and my workaround 
> was to point my opam repository to something before 5.3:
> opam repository set-url default 
> git+https://github.com/ocaml/opam-repository.git#2e81d1953c37347d78d994b71ede87c5f6f6e207
> The running the `make lock pull` showed me some other error I was able 
> to fix, and voila re-setting my opam-repository to
> opam repository set-url default https://opam.ocaml.org
>
> Worked than fine. But as you mention, it is very very brittle. In 
> combination with very confusing error messages.
>
> > (3) I often work on a library and a unikernel that uses it in tandem, 
> > so the `scope` argument to package config is essential, but I had to 
> > go digging in functoria .mli’s to find it. Is there documentation that 
> > I should have read about this? If so, I will go read it and maybe that 
> > will enlighten me.
> I never use the "scope" argument.
>
> > I’ve also tripped over things that are already in issue trackers like 
> > ‘mirage clean’ not cleaning out the duniverse directory and the 
> > current problem with OCaml 5.3.0 not being usable at all. After 
> > looking into the latter problem, I’m worried about the maintenance 
> > status of `opam-monorepo` and the `opam-overlays` repository it uses.  
> > The last commits were some time ago for both repositories, and it 
> > doesn’t look like there are replies to recent issues and PRs.
> True. Sad story.
>
> Maybe time to find a different path. All we need is customly-built C 
> stubs -- no need for recompiling all OCaml code for a unikernel. 
> Eventually there are better ways than this "opam-monorepo". (Hint: 
> there's 
> https://github.com/mirage/ocaml-solo5/pull/144/commits/3eb1861fad33abc895a581521cd20d77247a0bf9 paving the way... but we still need some mechanism to tag packages that require building with the MirageOS/OCaml C cross-compiler.)
> Of course, help (in terms of bugfixes, triaging issues, updating the 
> dune-opam-overlays) are very welcome.
>
> Hannes