<div dir="ltr"><div><div><div><div><div><div>Dear opam-devel,<br><br></div>As for previous OCaml releases, I am going through existing OCaml package to see what breaks in 4.05.0 to understand which parts of the ecosystem have to be upgraded early to provide a good user-experience at release time, and to find regressions in the compiler distribution. As I go over the invaluable opam-builder output ( <a href="http://opam.ocamlpro.com/builder/html/report-full.html">http://opam.ocamlpro.com/builder/html/report-full.html</a> ), I often find packages that have incorrect metadata, independently of 4.05.0, and I try to fix those when possible. Ideally, I think we should have no broken build in opam-builder all -- for example, broken packages create more work for me when triaging the build outputs of a new ocamlbuild version.<br><br></div>I find that *surprisingly many* opam packages have incorrect dependencies specified: they miss a lot of dependencies in the opam file.<br><br></div>In retrospect, this is not very surprising: programmers test their software in their working OPAM switches, which already have these dependencies installed (obviously to work on the software itself, but also because they tend to work with other projects that already depend on those; so asking a colleague to install the software on their own machine, for example, will not catch these missing dependencies as colleagues have correlated installed package sets).<br><br></div>It would be very nice if it was easy to ask opam to build a given local package / pin in a fresh, local, empty opam root. This would immediately catch these missing-dependencies problem, and it could be something we encourage packager to do after "opam lint" has succeeded.<br><br></div>(This does not necessarily need to be a hardcoded opam feature, a simple script may do. I suppose that the way to do this also differs on opam 1.x and opam 2.x).<br><br></div>Relatedly, I think that this phenomenon of correlated-dependencies can explain why certain kinds of Continuous Integration are more effective than others at catching those: opam-builder is very good at this, as it always build packages in an empty environment (this is made by cleverly caching builds to avoid rebuilding dependencies in that case), while the datakit CI on the opam-repository is not doing such a good job at detecting this specific issue, because it tends to test packages changes by update actions on top of an existing repository -- this difference is good as it means that datakit will exercise other update paths and scenarios, and catch other kind of issues.<br></div>