-
Notifications
You must be signed in to change notification settings - Fork 41
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
Sphinx 1.7 changed more APIs #73
Comments
Fixed in 8276fa8 - neglected to add commit msg hook. (It's a day.) |
Well, let's leave this open since it's not actually "fixed" aside from the dependency update. I would certainly like to support Sphinx 1.7 sometime. |
I'd really appreciate you supporting Sphinx 1.7. If there is anything people can do to help with that, please let us know. |
@rixx Not a lot that can be done besides somebody deep-diving to identify exactly what breaks on our end, what the diff was in Sphinx which caused it, and figuring out how we can adapt to get back to functionality. Typically involves a lot of either duck typing or explicit Sphinx version checking, which we already have in a few places (though I may be partly remembering Alabaster). As usual preference is on the former ("can I import module X / does object Y have attribute Z?") over the latter ("if Sphinx 1.7, do X, else do Y"). |
This might only be moved SphinxStandaloneReader module. Will try. |
Prepping a PR. |
Or something. See e.g. invocations exploding when it attempts to import Releases 1.4.0 on travis recently (with no changes on my end on either project):
(link: https://travis-ci.org/pyinvoke/invocations/jobs/357642688#L573-L593)
Kinda frustrating since it's not like that particular class is marked as being private or anything, but, such is Sphinx.
Need to either dial back Releases' setup.py (which I'm not a fan of but given Sphinx has broken us two minor releases in a row, seems prudent...) or dive in and add more conditional imports and such.
The text was updated successfully, but these errors were encountered: