Also fix some links in index.
Details
- Reviewers
roshi tflink - Maniphest Tasks
- T164: convert docstrings to sphinx format
- Commits
- rLTRN1af4d1ccff72: docs: convert libtaskotron docstrings to sphinx
Docs look better.
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
All the included changes look fine to me. It's a good place to work from moving forward.
Overall, it looks really good. Just 2 little things that I think could be improved
libtaskotron/check.py | ||
---|---|---|
89–90 | The docstring here is appended to the rendered docs in sphinx and is rather confusing. If nothing substantive is being added here, I think it should be removed. | |
114–115 | I'd like to see this docstring changed slightly to make it more clear that this is setting the outcome. The values can stay with the constructor but the param should be listed |
libtaskotron/check.py | ||
---|---|---|
89–90 | We will have to tweak Sphinx rendering, I'd like it to display __init__() method header as well. But in this case, yes, I'll remove it. I was afraid that if you use an IDE capable of displaying docstrings, you wouldn't see any documentation when creating new CheckDetail instance. But at least with Spyder, it displays combined class+init documentation, so it's fine. | |
114–115 | Sphinx solved this for us - it does not include property setter documentation into the generated docs at all: So we can either document the property fully in the getter, or in the class docstring. Since all of our other attributes are documented in the class docstring, I think it's more consistent to put it there. So I removed these See class documentation strings, and outcome is no longer visible in the generated docs as a standalone item. |
- convert file_utils to sphinx
- convert python_utils to sphinx
- convert rpm_utils to sphinx
- convert logger to sphinx
- convert koji_utils to sphinx
- convert bodhi_utils to sphinx
libtaskotron/check.py | ||
---|---|---|
114–115 | is the intent of the outcome() method pair to not be used much? It seems somewhat unwise to not document them at all, otherwise |
libtaskotron/check.py | ||
---|---|---|
114–115 | It's not a method, it's a property, therefore it externally looks and behaves as an attribute. And as all other attributes, it's documented in the class docstring. Do you think it's hard to find? |
Looks good to me, thanks for taking care of this
libtaskotron/check.py | ||
---|---|---|
114–115 | nvm, I was reading this incorrectly :-/ |
The docstring here is appended to the rendered docs in sphinx and is rather confusing. If nothing substantive is being added here, I think it should be removed.