Centralized hosting, predictable URLs, etc.

[aantron]

This is a major goal of odoc.

Also suggested in https://discuss.ocaml.org/t/1841/56, among other places.

[dbuenzli]

I wouldn't say this is an odoc issue per se, that's an infrastructure problem orthogonal to odoc. The major goal of odoc should be to produce docsets regardless of where they will be deployed.

[pmetzger]

@aantron So, is there currently a repo for docs.ocaml.org that this could be moved to? (And in fact, if people are working on that web site, perhaps there should be a public repo for it so people can start helping to make it a reality...)

[aantron]

@pmetzger I'll have to get back to you on that. Not sure how this should be organized, yet. A separate, public, and well-advertised repo is probably a good idea, though. Going to look into it.

We'll probably want to generate as much OCaml docs as we can using odoc+odig, and post that, to get started.

[hannesm]

FWIW scripts which run http://docs.mirage.io are published at https://github.com/mirage/docs

[avsm]

I'm working on a fairly large update of the opam package build infrastructure using buildkite.com as the coordination engine (this lets us do multiarch/os builds). I'll write a separate post about it shortly, but the tl;dr is that we should be well positioned to give you daily snapshots of all the cmt[i] files in a bulk opam build, and the required VM horsepower to process that into docs.ocaml.org. What is needed is the code in between the opam build artefacts and the VMs to generate the site :-)

Note that docs.mirage.io is a PoC -- we need to be able to do better index generation and package selection in particular, so perhaps extending those scripts is a good step in the direction of a full docs.ocaml.org

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[pmetzger]

I'm not sure this doesn't remain an issue worthy of consideration. Closing it automatically seems unreasonable...

[aantron]

@pmetzger We closed it as we are currently not working on it, and won't in the immediately foreseeable future. Stale issues are still considered and can of course be discussed, in fact I changed the stale message after this issue was closed to read:

odoc/.github/workflows/stale.yml

Lines 16 to 31 in 9a94324

	stale-issue-message: >-
	This issue has been automatically marked as stale because it has not
	had recent activity. It will be closed if no further activity
	occurs. The main purpose of this is to keep the issue tracker
	focused to what is actively being worked on, so that the amount and
	variety of open yet inactive issues does not overwhelm contributors.
	An issue closed as stale is not rejected — further discussion is
	welcome in its closed state, and it can be resurrected at any time.
	odoc maintainers regularly check issues that were closed as stale in
	the past, to see if the time is right to reopen and work on them
	again. PRs addressing issues closed as stale are as welcome as PRs
	for open issues. They will be given the same review attention, and
	any other help.

This issue in particular is something we definitely still want to address, but we may end up doing it in another repo, when the time comes to actually work on it. There will probably be some kind of tool or system that builds or manages the centralized docs, so it will be discussed wherever that ends up being developed.

[Julow]

Even though it's not written anywhere, changes to the URLs are considered breaking changes and happened only in edge-cases.
ocaml.org successfully hosts documentation.

This issue seems fixed.