New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix cross reference #3273
Fix cross reference #3273
Conversation
Great work, it is really a huge task to get Sphinx and friends to automatically document the complete API nicely (including just what you want). I was wondering. Have you built the API by just listing the modules in a top Also, have you tried controlling which members are listed by |
I did look at what you mentioned, and I found it that it doesn't play well with how hyperspy is currently structured. This is more simple after the split but still came to the conclusion that defining what API modules goes where explicitly is more straightforward and simple rather than using templates that needs to be adapted to hyperspy's need to generate the API automatically. The fact that the documentation is succinct and that it is difficult (and slow) to troubleshoot when something doesn't work, did put me off quite a bit. |
I see, thank you for clarifying. I'm quite sure I'll learn some nice tricks from this PR: feel free to ping me for a review.
Having a curated API reference, as you introduce here, rather than one automatically generated (as in kikuchipy/orix) can be straightforward to maintain, if the API doesn't change too quickly, and one remembers to add new members (classes, methods, functions, etc.). We had a curated API for orix, but it quickly became outdated as a constant stream of new features weren't continuously added... Just something to be aware of. |
The important point of this PR is that the doc build will fail if a cross reference is broken. This is important, because when a new API is added, it is documented and it comes cross references to the relevant API - usually we do this fairly well. This should catch anything new and missing from the API reference. I would expect that it is rare (when restructuring a module, for example) that we need to update the API reference manually, because:
|
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## RELEASE_next_major #3273 +/- ##
======================================================
- Coverage 80.86% 80.84% -0.02%
======================================================
Files 140 140
Lines 20399 20475 +76
Branches 4825 4838 +13
======================================================
+ Hits 16495 16553 +58
- Misses 2829 2859 +30
+ Partials 1075 1063 -12 ☔ View full report in Codecov by Sentry. |
6be9f89
to
add17e0
Compare
I agree that as long as contents of modules (functions and classes with attributes and methods) are listed automatically the maintenance burden should be reasonable. |
add17e0
to
0df49ce
Compare
@hakonanes, @jlaehne, do you want to review this PR? |
…ers` as `Component` property
0df49ce
to
5281d51
Compare
I'm sorry, but I don't have time until Monday... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stupendous amount of work this must have been, I'm impressed!
I've gone through 131/142 files here on GitHub. I've just briefly checked the API reference in the docs built from this PR. Plan to look through the remaining files tomorrow or Sunday.
No need to commit my suggested changes, feel free to do the changes yourself.
"module", | ||
} | ||
|
||
# if Version(numpydoc.__version__) >= Version("1.6.0rc0"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this be useful later on? I see version 1.6 of numpydoc was released in August (here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it could be, to check the formatting of the docstring, but I think that this is not a priority. I don't know how much editing is required in the current state but better in a separate PR.
@hakonanes, please let me know when you finish your review. |
I'll finish tomorrow evening, sorry for the delay. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here're the rest of my comments. Again, good work!
5281d51
to
93a1719
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @hakonanes, I fixed the typos and the links.
@jlaehne, do you want to review this PR?
"module", | ||
} | ||
|
||
# if Version(numpydoc.__version__) >= Version("1.6.0rc0"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it could be, to check the formatting of the docstring, but I think that this is not a priority. I don't know how much editing is required in the current state but better in a separate PR.
I'll try to browse over it these days, but I don't think I'll manage an as detailed review as @hakonanes |
This PR fixes many links to the API references. Enable sphinx "nitpicky" to check that there is no broken reference.
With the API changes, it is important that the reference are working, as it helps identifying if something is missing from the API references, beside being convenient to navigate.
Progress of the PR
- [x] use
numpydoc
- [x] enable sphinx "nitpicky" to check any broken reference.
upcoming_changes
folder (seeupcoming_changes/README.rst
),readthedocs
doc build of this PR (link in github checks)