[ANN] opam-check-all: Are your packages broken for the upcoming OCaml releases?



Hi everyone,

OCaml 4.07.0 is not far from being released, and, as usual, some opam packages need some adjustments or a new compatible release.
To be able to track which packages need fixes I’m please to offer the following webpage which tries to summaries this:


This bleak (sorry for that) webpage also allows to select the compilers you want to check. For instance:

Available compilers are listed on the main page.

This webpage is for the moment very bleak and needs lots of improvements but is being actively developed.
For the moment the checks are not updated automatically but it’s definitely the next feature I’m planning to add.

The source code is available here:

The purpose of this tool is very close to obi announced here and other similar tools like opamcheck, opam-builder and ows. My apologies if I’m making yet another checker here. opam-check-all started as a small shell script but I recently decided to rewrite it fully as a small OCaml program and use it to check the next OCaml release. I plan to keep it small and easy to use as much as possible.

But anyway, if one day you happen to be bored and you want to fix opam packages, this webpage will be here to help you.

Replacement for Opam Weather Service

This is great.

I think it would be a good idea to only show the last 1 or 2 versions of each package. There are far too many versions shown, giving a much worse impression than is necessary.

Also, what’s the difference between red (fail) and grey. Is grey just not attempted? Or constraints not matching?


The goal is to do a sanity check for every packages and if possible add the necessary constraints where possible. I can add a mode to just show the last version but I think the default one should still show every versions.

Grey means: not available for this switch (either a dependency or the package itself).


OK I see – so the goal is to have no reds anywhere, and no grays on the latest version. Maybe we can summarize that so there isn’t as much noise ie. only show an old version if it’s red, and always show the latest version.


Something that would be nice is to be able to filter the list per package maintainer.


That would indeed be good, then people could look at just what they’re responsible for.


so the goal is to have no reds anywhere, and no grays on the latest version.

I think the main goal is just no reds anywhere. Greys are unavoidable, when an old package version breaks with a new compiler all you can do as add a constraint on it. Ideally packages where the latest version is grey on 4.07 would also do a new green release – but that can happen after the release of 4.07.


I’ve added some new features. For example it is now possible to filter the table in such a way to see only packages that fail on 4.07.0+beta2 but not 4.06.1.

Feel free to take a look at the (much shorter) list and fix it if it’s not related to any compiler bugs:

You can also do the same thing between 4.05.0 and 4.06.1, you just need to change the filter accordingly.


@kit-ty-kate Was the list of packages updated? I’m surprised to find benchmark 1.3.1 since 1.5 is out.


yes, it has been updated less than a week ago but it’s displaying every packages not just the latest ones.
To see everything just go to the main page or select the filters accordingly.


Something that would be nice is to be able to filter the list per package maintainer

I very much second that.


@bluddy I just added this feature. There is now a filter to only show the latest version of each packages.


FYI the “only show packages that have different build status between each compilers” feature doesn’t seem to apply for packages that were green but are now gray, thus missing much of the info.


@Chris00 @perry @rixed Filter over maintainers is now available. For example:


Nice job, @kit-ty-kate! This tool is so awesome!

Would it be even remotely possible to implement a sort by rev-dep count? That would indicate the highest priority items for the community to update.


Thanks @kit-ty-kate, after all these systems eventually one that has exactly the right set of filters a maintainer needs.

One last thing however, the notion of failure is wrong not precise enough e.g. on this page, vg is not to blame, it’s its js-of-ocaml dependency, this should be distinguished somehow.


Fixed and deployed. I’ve introduced a partial failure state and they are displayed as orange instead of red.
I’ll maybe add some other filters to filter out partial failures at some point but I’m not sure that’s needed.


Thanks very much !

As far as I’m concerned I don’t think it’s needed. I’m interested in knowing one of my package is still failing, but I just wanted to know it was not my fault.


Btw. I’m not sure also whether you can distinguish this. But for example this error seems to be an infrastructure problem not a problem with the package itself.


In this case it’s not an infrastructure problem, it’s the checksum being wrong but the error message is not really helping (see https://github.com/ocaml/opam/issues/3393)