Closed bitprophet closed 6 years ago
Fixed in 8276fa81b7a64f08e0afa3651f7d1b921be1d556 - 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.