Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
De-randomize doc builds#5769
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
👍 I think this fails due to the issue fixed by#5770 |
Cool. This is very welcome work.
Looking at the code, nothing obvious leaps out as to why this would be the case... As an experiment, you could try monkey-patching the hash function in
If you can reduce this to a simple standalone example where the attributes don't always come out in order, I suspect the Sphinx folks would be amenable to fixing it.
I can certainly reproduce this one. I might spend a little time looking.
Which ones? I wonder if this is due to something not quite right in the recent limits changes or possibly something like#5767 |
Inheritance diagrams should be fixed bysphinx-doc/sphinx#2210. |
I don't know how these few always come out different somehow, but
I was thinking more of#5647, though. |
This keeps aliased colours like gray/grey or fuschia/magenta in the sameorder every time.
This ensures that the same plots are produced between builds.
Looks like this is passing again with the rebase; I think it can go in if there are no other issues and we can leave the other stuff for other PRs. |
| @@ -16,6 +16,7 @@ | |||
| randomDists = ['Normal(1,1)', ' Lognormal(1,1)', 'Exp(1)', 'Gumbel(6,4)', | |||
| 'Triangular(2,9,11)'] | |||
| N = 500 | |||
| np.random.seed(0) | |||
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 would suggest adding a comment that the random seeding is only to make the example reproducible
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.
There are many of these in the examples without any comment; add them as well?
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.
There are many issues with the examples so I wouldn't expect to fix all of them but I would like to do this in new examples
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.
Done.
A few inline comments otherwise 👍 I agree that leaving the other stuff for a subsequent PR is fine. Looks like the examples that list above are mainly in the mpl_toolkits axes_grid1 and axisartist. |
That's fine as long as we remember to rebase that against upstream Sphinx periodically. While I'm normally against monkey-patching, in this case I think I'd prefer monkey patching those two small methods in Sphinx because it places less burden to keep up with Sphinx. |
Nah, I don't think that's necessary; it only ensures that consecutive builds give consistent names, but it won't make too much difference to the results. |
Thanks. We can always fix the examples later then if there are several others with the same issue |
Based on some issues I've found trying to get consistency out of#5743, this disables some needless randomness in the documentation (by setting seeds, or dropping it altogether). There are still a few things that remain:
boxplot_demo2.py; I guess the font size and bbox calculation are not always done in the same order.