Central OPAM documentation site

The details contained here are the key missing step. If we did in the Rust way, then the url scheme would be docs.ocaml.org/package/version/<html>, but the cross-references would not be shared. This would make every package doc a standalone one, unless you had a different scheme in mind?

I’m definitely interested in getting nixpkgs up and running in our infrastructure and would welcome concrete PRs towards this. But to get cross-references working, odoc essentially needs to do a massive link across a lot of cmt[i] files, and so again if they are built with different versions of dependencies the CRCs wouldn’t match.

Before accepting something into the ci infrastructure, it’s definitely important to see what it looks like as an outside service. That’s why I setup docs.mirage.io externally so it’s easier to experiment with. I’d be happy to see a prototype of the scheme you have in mind (e.g. using the excellent cloud.drone.io) in order to evaluate how to integrate it into the opam CI. You can consider the latter to be a fancy DSL that runs pure functions over input git branches and stores the output in another git branch. So anything you build as a shell script or Docker container can easily be transplanted into that infrastructure later.