[Python-modules-team] Bug#958848: Bug#937769: python-funcsigs build-dependencies now unsatisfiable in testing, removal of pypy-pytest

[peter green]

On 04/06/2020 23:12, Thomas Goirand wrote:
> On 6/4/20 10:33 PM, peter green wrote:
>> A few days ago Sandro Tosi uploaded the python-unittest2 and
>> python-funcsigs source packages. It seems that both of these were
>> effectively "team uploads" though they were not marked as such.
> A few years ago, I've been flamed, them banned from the DPMT for less
> than this... Though I don't think we should put the blame on Sandro. He
> did a lot and we should be thankful for his work on Python 2 removal.
I'm not looking to place blame on anyone here, I am just looking to get broken build-dependencies in testing dealt with.
> The thing is, funcsigs is a backport of the PEP 362 function signature
> features from Python 3.3's inspect module (as per the package
> description), so it should in fact go away if possible.

I don't have any objection to it going away as long as the reverse-dependencies are dealt with. It's now down to four rdeps, two of which (pagure and nipype) are not in testing and one of which (kombu) is tagged pending with you on the uploaders list.

>   I'm really not
> sure what's going to be the faith of pypy-pytest, maybe it should be
> replaced by pypy3-pytest? If I remember well the discussion, we wrote
> that we would just disable the tests for things depending on python 2
> test suites. Maybe this includes pypy-pytest?

Earlier in the discussion on bug 937769 the following was posted by Stefano Rivera (pypy maintainer)

Stefano> pypy itself (the python 2.7 pypy) will continue to exist for the
Stefano> foreseeable future, to support building pypy3. But we don't need to ship
Stefano> modules for it. I'd be pretty happy if we had working virtualenv, and
Stefano> nothing else.

And the following was posted by Ondřej Nový (pytest maintainer)

Ondřej> I'm perfectly fine with removing pypy-pytest binary package and all other
Ondřej> dependencies in chain. It's painfull to maintain it.

Based on this it seemed that getting rid of pypy-pytest was the desired way forward.

I went through the reverse (build-)depends of pypy-pytest and thier transitive reverse (build-)depends, making the assumption that if the pypy-<module> package was removed from a source package the build-dependencies on any pypy package could also be removed. I concluded that in order for pypy-pytest to go away.

* The pypy-atomicwrites, pypy-pluggy, pypy-py pypy-setuptools-scm pypy-wcwidth pypy-importlib-metadata and pypy-zipp binary packages need to go away (or alternatively have their tests disabled). These packages are involved in build-dependency loops with pytest, so they need to be dealt with at the same time as pypy-pytest. All of these have the debian python maintainers team in the maintainer field which according to the team policy indicates "Team in ``Maintainers`` is a strong statement that fully collaborativemaintenance is preferred. Anyone can commit to the Git repository and uploadas needed" so dealing with these as a block should not be an issue.
* vanguards needs to stop build-depending on pypy-pytest

According to the discussion over at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932820 vanguards uses pypy for performance reasons, the long term goal would be to move to pypy3 but there are (or at least were when that bug was last active) apparently some tooling issues.

I filed bug 958848 on pytest ccing the vanguards maintainers, Chris Lamb (part of the team that maintains vanguards but not directly involved in it's maintenance) responded suggesting the possibility of running the vanguards testsuite under python3. Obviously running the testsuite with a different version of python from that which will be used on the running system is sub-optimal, but it's probably better than not running the tests at all.

I took Chris's patch, tested that it builds the package succesfully, prepared a debdiff and posted a rc bug report on vanguards. I am now waiting to see if the maintainer responds.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/python-modules-team/attachments/20200605/eba30999/attachment-0001.html>