[Python-modules-team] Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

[Sandro Tosi]

Hey Dmitry,
please note that the relatively old version of sphinx we have in
Debian now makes it not possible to upgrade scikit-learn
(https://github.com/scikit-learn/scikit-learn/issues/16087#issuecomment-573092993),
which we require to upgrade as the scikit-learn version we have in
unstable now FTBFS due to other modules/libraries being upgraded,
compatibility which is fixed in the new version and... you got the
idea :)

I understand it may be more work, but i suspect that splitting sphinx
1.8 and 2.* is probably the best way forward to allow continuous
compatibility with already-existing packages and the upgrade of those
modules that require a newer version.

please let me know what you think

On Tue, 24 Dec 2019 22:18:37 -0500 Sandro Tosi <morph at debian.org> wrote:
> On Sun, Dec 22, 2019 at 4:22 PM Dmitry Shachnev <mitya57 at debian.org> wrote:
> >
> > Hi Sandro!
> >
> > On Sun, Dec 22, 2019 at 02:47:10PM -0500, Sandro Tosi wrote:
> > > > The current version packaged in Debian is very outdated,
> > > > even in unstable. Please consider packaging the current
> > > > upstream release.
> > >
> > > I'm echoing this request: the just released numpy/1.18.0 requires
> > > sphinx >= 2.2.0, so we cannot upgrade numpy without an updated sphinx.
> > > please consider package it at the earliest.
> >
> > Unfortunately sphinx ≥ 2.0 dropped support for Python 2.
> >
> > So I should either wait until all blocking bugs of #938528 are resolved, or
> > introduce a new source package like sphinx-python2 for the old version.
>
> i think there a quite too many packages blocking 938528 (counts is
> 100), so yeah maybe a src:sphinx2 (to track 1.8.5) and src:sphinx (to
> track 2+) seems like the best solution to keep old packages around and
> not prevent progress for the modules more forward-looking.
>
> > However the latter solution will mean that we can no longer have shared
> > sphinx-common and libjs-sphinxdoc packages, and we will need to have two
> > versions of dh_sphinxdoc too (or one version that will generate different
> > dependencies for old and new sphinx). This is something I wanted to avoid,
> > because it is extra work for supporting a Python 2 version that will be
> > dead in a few days.
>
> hm, that's a good point indeed; i'm not sure we can drop python-sphinx
> and make all of those packages RC
>
> > Recently your script bumped many Python 2 removal bugs to RC, with the
> > intention to accelerate porting those packages to Python 3 (or getting them
> > removed). Maybe better to wait a couple of months and then just upload new
> > Sphinx and break its Python 2 reverse build-dependencies?
>
> only 49 of those 100 blocked packages are currently RC, so it will
> take quite more time i suspect; also some of those packages are sphinx
> extensions, that will have to go at the same time as sphinx maybe?
>
> > Can you patch old Sphinx support into numpy for the time being?
>
> tbh, i'd rather not :) maybe you can consider uploading 2.2+ to
> experimental, just to see if there's any breakage with the new version
> (even for packages already using python3-sphinx), and i can upload
> numpy in experimental
>
> Cheers,
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
>
>