[opam-devel] Feature request to get correct dependencies: build this pin in a fresh local root

[Gabriel Scherer]

Dear opam-devel,

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 (
http://opam.ocamlpro.com/builder/html/report-full.html ), 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.

I find that *surprisingly many* opam packages have incorrect dependencies
specified: they miss a lot of dependencies in the opam file.

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).

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.

(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).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20170307/a52feb74/attachment.html>