ENH: Build API entry usage graphs#12013
Conversation
|
@drammock ready for review/merge from my end It's not perfect but it does give us some targets for things to add. After this is merged we can create a new issue, mark it as easy, and link to the |
drammock
left a comment
There was a problem hiding this comment.
Nice addition. Some comments:
-
graph is basically unusable because the nodes are so small and spread out. Does the SG API let you adjust
nodesepor other graphviz params? -
It's interesting to note that this has similar problems as the minigallery directive. Minigallery will (sometimes! not always) link from an API entry to a tutorial even if the func/meth/class is merely mentioned in the rST prose of the tutorial (i.e. not actually used in the executed code). An example is the mne.viz.plot_topomap minigallery's link to the working with sensor locations tutorial. An example where a method gets zero minigallery entries (despite mention in a tutorial) is Epochs.del_proj(), which is mentioned in the Epochs overview tutorial. It even sometimes fails to create a minigallery link when the API element is in executed code, as in Label.center_of_mass which gets no minigallery but is used in the point spread tutorial The "unused API entries" appears to have similar (the same?) problems.
|
feel free to merge if you don't want to address those points / if they're best addressed upstream in SG (they probably are) |
|
Yeah those are indeed all upstream SG issues |
|
... except the node stuff. That we could probably change with this in |
|
With defaults I get: With a bunch of stuff tweaked I get: Visible here: It's not perfect (there is some overlap) but it seems much more usable/readable. |
|
much better, thanks! |


Toward #11114, let's see if we can even get a graph to show and if it looks okay. If we can't, we should just close #11114 since the feature will not be usable for us.
If it does look okay, I'll add it to the docs somewhere and we can merge.