You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently most of the API functions simply wrap their Python counterparts and forward the docstrings for use in the Julia REPL, e.g.
julia>using ArviZ
? plot_parallel
This works for the REPL but not for generating documentation.
Moreover, the Python docstrings are in ReST format, which Documenter can't format well, and the code examples, style, and type are Python specific. In the future, some functions may have slight API changes.
It's probably best going forward to adapt ArviZ's docstrings for the API functions in this package. The downside to this is the need to synchronize docstrings across packages, but for the reasons listed above, I think this is the better option.
The text was updated successfully, but these errors were encountered:
sethaxen
changed the title
Adapt ArviZ documentation
Adapt ArviZ docstrings
Nov 13, 2019
I figured out how to have two types of docs in 2 contexts. For every function forwarded without modification to arviz, we define two types of documentation. The documentation that appears in the docs will just consist of the link to the same function in ArviZ's docs. To make the help messages in the REPL useful, we'll make them show the ArviZ docs.
We'll only define non-linking docs for functions that have been modified in some way. Thus the ArviZ.jl docs will also serve as a diff between the two packages. Then there's no need to adapt ArviZ's docstrings except for those cases where we changed something.
Currently most of the API functions simply wrap their Python counterparts and forward the docstrings for use in the Julia REPL, e.g.
This works for the REPL but not for generating documentation.
Moreover, the Python docstrings are in ReST format, which Documenter can't format well, and the code examples, style, and type are Python specific. In the future, some functions may have slight API changes.
It's probably best going forward to adapt ArviZ's docstrings for the API functions in this package. The downside to this is the need to synchronize docstrings across packages, but for the reasons listed above, I think this is the better option.
The text was updated successfully, but these errors were encountered: