Conversation
| 'nbformat', | ||
| 'sphinx>=1.8', | ||
| # https://github.com/spatialaudio/nbsphinx/issues/825 | ||
| 'sphinx >= 1.8, < 8.2', |
There was a problem hiding this comment.
See my comment in #825 (comment), I think that Sphinx 8.2.2 shoud now work with nbsphinx (though the explicit imports in #826 remain the correct solution)
| 'sphinx >= 1.8, < 8.2', | |
| 'sphinx >= 1.8, != 8.2.0, != 8.2.1', |
There was a problem hiding this comment.
@AA-Turner @mgeier I can confirm that sphinx 8.2.2 passes with current nbsphinx for now
There was a problem hiding this comment.
Thanks for the update!
I'm still getting a warning related to felix-hilden/sphinx-codeautolink#173.
I will un-pin Sphinx when this is done. I might also re-think the testing strategy for warnings, because keeping up with them is quite time-consuming.
I have just made a new nbsphinx release which still blocks Sphinx 8.2+.
There was a problem hiding this comment.
@mgeier I am not sure that should make you pin sphinx. sphinx-codeautolink is not a dependency of nbsphinx. The only reason you see that warning is that it is used in nbsphinxs own documentation (and thus triggered when you run that in ci) In my projects I use nbsphinx but not sphinx-codeautolink
There was a problem hiding this comment.
Indeed, to Matthias' point about testing strategy for warnings, enabling deprecation warnings for the documentation build (or non-core dependencies) probably isn't needed and may be unhelpful in this case.
In general, I think pinning upper version bounds is not the right approach, but given the slew of incompatibilities introduced by Sphinx (in part involving 3rd party dependencies), I think it is best for my sanity and for most casual
nbsphinxusers to restrict Sphinx upgrades for now.I hope it will become easier to support Sphinx upgrades at a later point.
This PR includes #823 in its entirety and parts of #826.