-
Notifications
You must be signed in to change notification settings - Fork 43
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 docs build and reduce warnings #231
Fix docs build and reduce warnings #231
Conversation
google-auth-oauthlib==0.4.4 | ||
google-pasta==0.2.0 | ||
gpflow==2.1.4 | ||
gpflow==2.1.5 |
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 think upgrading GPflow should be left to some other PR, probably it won't break any of the code, but just in case...
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.
bear in mind this is the constraints for CI, not for the library itself, so this number isn't used by users
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.
Nevertheless, it might make sense to pin the versions of key libraries in requirements.txt, at least with ~. Though I'd certainly hope that a minor point revision change to gpflow would never break anything!
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.
gpflow doesn't use semver. Patch versions are meant to be backwards compatible
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.
We already pin gpflow to 2.1.x in setup.py, so I would personally be happy with this update. Also I'd be very sad if the tests didn't catch a break.
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.
ok, if patches should be backward compatible lets go with the upgrade
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.
Looks good so far... why some notebooks didnt appear in manual docs build at the end?
A change to docutils meant nbsphinx was automatically ignoring notebook files with lines longer than a (not very big) limit. Upgrading nbsphinx fixed it. |
@@ -1,3 +1,8 @@ | |||
# --- |
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.
@joelberkeley You don't happen to know why this isn't working? I'm trying to mark this notebook as orphan (as described in https://nbsphinx.readthedocs.io/en/0.8.3/orphan.html) so we don't get a warning that it's not part of a TOC (it's only included as a doc link in the FAQ).
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.
no idea. I've never worked with headers for notebooks
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.
all good, tox build successful, no warnings shown and all notebooks seem to be there
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.
Looks good to me!
The docs build was temporarily broken due to a nbsphinx bug. This PR:
Note that I may need to separately update the repository config to mark the new check as required for merges to develop.