Bug#943135: [Python-modules-team] Bug#938756: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[Scott Kitterman]

On April 20, 2020 2:36:00 AM UTC, peter green <plugwash at p10link.net> wrote:
>(using -quiet aliases where multiple involved packages have the same
>maintainer listed.
>
>Hi
>
>I have just been running some self-contained buildability tests on
>bullseye and these tests indicated that the python-linecache2 and
>python-traceback2 source packages have been unbuildable in testing for
>170+ days. Both are fixed in unstable by removing python 2 support, but
>can't migrate to testing because the python-unittest2 binary package
>depends on the python-traceback2 binary package. The python2 removal
>bug for python-traceback2 lists python-funcsigs as a blocker. The
>python2 removal bug for python-traceback2 lists nipype and numba as
>blockers.
>
>unittest2 and python-funcsigs seem to be just module packages, so
>dropping python2 support should be simple. numba seems to be a case of
>leftover recommends and test-triggers so that should be a pretty easy
>job to clean up too.
>
>nipype on the other hand looks like it needs a new upstream release. It
>seems this was previously blocked on a package passing new, but said
>package has now passed new.
>
>python-funcsigs seems to have a build-dependency on python-traceback2
>but not a binary dependency, this suggests that the dependency is only
>used to run tests at build time.
>
>nipype and numba are not currently in testing.
>
>This IMO leaves three potential ways forward
>
>Option 1: fix all four packages to be python 2 free.
>
>Option 2: Remove python2 stuff from traceback2, python-funcsigs and
>numba. Break the dependencies of nipype in sid.
>
>Option 3: Remove python2 stuff from traceback2, modify python-funcsigs
>so it still builds the python2 package but does not run tests with
>python 2.
>
>If the maintainers of nipype are willing to upload a python 3 version
>soon, then option 1 is IMO the preffered way forward, but a new
>upstream version is not something I would be prepared to NMU.
>
>Otherwise I am inclined towards option 2. Depending on what responses I
>get to this mail I may implement this option through NMUs later.

Nipype in Unstable is already all kinds of broken.  I'd ignore further breaking it your analysis.  I'd suggest move forward with option 2.

Scott K