Since Documenter v1.3.0, Documenter has been including Sphinx inventory files in the docs build. DocumenterInterLinks.jl then provides functionality for specifying a package whose docstrings we want to be able to link to.
Instead of duplicating the API docs of our component packages here, we should instead simply re-export each package, deferring to their documented APIs. Then the docs for this meta-package would focus on usage examples that combine the component packages, linking to the corresponding docstrings in each package.
The only not-great aspect of this plan has to do with the docstrings for functions in MCMCDiagnosticTools and PosteriorStats that have new methods defined in extensions in InferenceObjects. Currently those docstrings are only included here. If using DocumenterInterLinks here, we should define those docstrings in the InferenceObjects docs. This will still result in docstrings for various methods of e.g. rhat being spread out across multiple docs pages for different packages, but this won't be so bad if InferenceObjects also uses DocumenterInterLinks to link in each overload's docstring back to the more abstract method defined in the original package.
Since Documenter v1.3.0, Documenter has been including Sphinx inventory files in the docs build. DocumenterInterLinks.jl then provides functionality for specifying a package whose docstrings we want to be able to link to.
Instead of duplicating the API docs of our component packages here, we should instead simply re-export each package, deferring to their documented APIs. Then the docs for this meta-package would focus on usage examples that combine the component packages, linking to the corresponding docstrings in each package.
The only not-great aspect of this plan has to do with the docstrings for functions in MCMCDiagnosticTools and PosteriorStats that have new methods defined in extensions in InferenceObjects. Currently those docstrings are only included here. If using DocumenterInterLinks here, we should define those docstrings in the InferenceObjects docs. This will still result in docstrings for various methods of e.g.
rhat
being spread out across multiple docs pages for different packages, but this won't be so bad if InferenceObjects also uses DocumenterInterLinks to link in each overload's docstring back to the more abstract method defined in the original package.