docs: create a Sphinx domain extension to document preference settings#3567
Conversation
82e4572 to
8b0f500
Compare
|
Admit I'm not a Phyton guy, but I get the following (missing Python dependency?): |
|
@georgweiss Yes, apparently I developed the extension for a more recent version of Sphinx, so I had to update the Sphinx version in the I just pushed it, you might have checked out the PR before that. But somehow the ReadTheDocs output doesn't show the preferences, and I'm currently trying to fix that too… |
8b0f500 to
5768365
Compare
There we go! That was definitely a mistake on my part. Here's the output if you want to see it: https://control-system-studio--3567.org.readthedocs.build/en/3567/preference_properties.html |
|
Is it possible to have the source link to a file hosted in the read the docs? I think we host the docs inside of phoebus and we might want an airgapped network. |
|
@jacomago technically, it should be possible, but I'd argue there is no need: the entirety of the properties file is rendered on the page. I think the |
This is quite a bit more Python code than the previous implementation, but gives the following benefits: - a structured, more readable output than code blocks of properties files - more readable descriptions, now that they are with markup - a more complete table of contents in the side bar - referenceable packages and preferences in the documentation, by using the new "preferences:pack" and "preferences:pref" roles - "[source]" links to GitHub for viewing the properties file - indices of preferences, in the "genindex.html" and "preferences-index.html" pages
5768365 to
ff3dde5
Compare
|
Updated to fix merge conflict. |
This changes how the preference settings are fetched and put into the documentation.
Instead of creating the
preference_properties.rstfile inconf.py, this PR creates a Sphinx extension that parses the preference files, and outputs "objects", like Sphinx would do for documenting a Python or a C API.Some more information can be found here:
This is quite a bit more Python code than the previous implementation, but gives the following benefits:
A structured, more readable output than code blocks of properties files
More readable preference descriptions, now that they are with markup
A more complete table of contents in the side bar
Referenceable packages and preferences in the documentation,
by using the new
preferences:packandpreferences:prefrolesIf a document references a preference that doesn't exist, the Sphinx build will output a warning. This helps quite a bit keeping the documentation up-to-date.
"[source]" links to GitHub for viewing the properties file
Indices of preferences, in the "genindex.html" and
"preferences-index.html" pages
I've been running something similar to this for EPNix, and I found that once done, there's not much maintenance to do.
I have another PR ready after this one that changes the doc-comments inside properties files so that they have proper markup, but I wanted to propose a PR as small as possible (and it's already quite big).