-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Document functions on module pages #10471
Conversation
Pull Request Test Coverage Report for Build 5679422072
💛 - Coveralls |
d491b29
to
a0403a8
Compare
One or more of the the following people are requested to review this:
|
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.
Thanks Eric, this looks like a solid start. I think we'll want to do more passes in the future improving the stories on these documentation pages, but that's definitely for another day. I've found that putting more of these methods on the same page seems to exacerbate CSS problems in the Pytorch theme, but hopefully that'll all be fixed by Furo anyway.
There's a few places where I think we need to be careful about .. currentmodule
handling that autosummary would previously paper over, but mostly this looks fine to me.
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.
Thanks, Jake! You're spot on.
Huh..the last commit resulted in a maximum recursion error 😱 But @jakelishman I suspect it wouldn't solve the UX problem either way -- I think the functions would still only show the function name, rather than the full or relative module, so it would make the import path misleading. -- Alternative idea. What if we stopped using Imo, that is a better user experience because it allows you to immediately see how to import the code object. That's especially useful on long pages where you forget what module you're on. Yes, it's more verbose in our I would split that out as a dedicated "prefactor" PR. |
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.
The UI of what is displayed is a bit of a separate question to the currentmodule
directive, which tells Sphinx what module the contained objects should be considered as part of. If you want all the module names shown, then we should set add_modules_names=True
to the root conf.py
. I'd worry a little about that being very noisy for individual functions, but it could be ok, and it's not my call anyway.
For functions where it might not be clear how they're imported from the docs structure, I think that probably more indicates that the current import structures in Qiskit / incomplete explanations in the documentation, tbh. qiskit.circuit.random.random_circuit
probably should just be available at qiskit.circuit.random_circuit
.
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.
I flicked through all the built documentation pages, and this looks like a good improvement to me. There's of course places where our styling could be improved, but we're hoping the switch to Furo will improve a lot of that immediately, and make the rest rather a lot easier to improve.
I pushed up a minor change to add some more autofunction
calls in a couple of files that I spotted them in.
* Document functions on module pages * Fix invalid functions * Revert visualization because each function is so big * Fix more issues * Use currentmodule * Show modules & fix recursion * Add some missing autofunctions --------- Co-authored-by: Jake Lishman <jake.lishman@ibm.com> (cherry picked from commit 025320f)
* Document functions on module pages * Fix invalid functions * Revert visualization because each function is so big * Fix more issues * Use currentmodule * Show modules & fix recursion * Add some missing autofunctions --------- Co-authored-by: Jake Lishman <jake.lishman@ibm.com> (cherry picked from commit 025320f) Co-authored-by: Eric Arellano <14852634+Eric-Arellano@users.noreply.github.com>
See #10455 for the motivation:
This does not migrate the visualizations module, though, since those functions tend to have huge docstrings with visuals included.
Some of our functions are documented on module pages but come from submodules, e.g.
qiskit.circuit.random.random_circuit
being documented onqiskit.circuit
. To make it clear that you cannot directly importqiskit.circuit.random_circuit
, this PR also changes our config to show the module path in code objects:Follow up PRs should consider re-exporting those submodule members in the top-level module so that we can revert this config.