Remove unittest2 usage from testtools

[mtreinish]

Currently testtools bases all of it's unittest extensions off of unittest2 instead of the stdlib unittest. At one point this made sense since unittest2 provided a stable base as unittest in stdlib added features. But it's been ~5 years since there was a unittest2 release (or a patch merged) and things have changed since then. The best example of this is of the supported python versions listed in the unittest2 project description/README only one is still supported by upstream python, 2.7, which goes end of life at the end of this year.

More specific to testtools the use of unittest2 causes a whole slew of issues because of differences in behavior with stdlib unittest. For example here a couple issues encountered:

https://bugs.launchpad.net/testtools/+bug/1467558 https://bugs.launchpad.net/testtools/+bug/1417803 mtreinish/stestr#238 testing-cabal/testtools#272

which are caused, at least in part, by unittest2. There are likely other bugs related to it that haven't been reported (or I just missed/forgot about). At this point it's better to remove the unittest2 usage and just rely on the upstream stdlib unittest which if nothing else is actively maintained. It'll improve compatibility using the testtools runner with stdlib unittest test suites and removes the class of bugs caused by the differences in unittest2.

Fixes #263

[hugovk]

+1

unittest2 is needed for Python 2.6, but that's no longer supported so it's better to use the stdlib unittest.

[stmcginnis]

Would be great to get this in. I ran into this over the last couple days, and took me quite awhile to track it down to the same conclusion and find this issue and PR.

[mtreinish]

+1

unittest2 is needed for Python 2.6, but that's no longer supported so it's better to use the stdlib unittest.

It's also needed for python 2.7 support, unittest2 was a rolling backport and included some of the test runner (mainly the loader) from stdlib added after 2.7. (I hit a similar issue in: https://github.com/mtreinish/stestr/pull/256 ). This is why the py2.7 CI jobs are failing here. I've opened up https://github.com/testing-cabal/testtools/issues/286 to discuss dropping 2.7 support. Once we stop supporting 2.7 in testtools this will be unblocked.

[mtreinish]

I'm not sure why travis has stopped reporting here, but now that we've dropped support for python 3.4 and python 2.7 this is passing: https://travis-ci.org/github/testing-cabal/testtools/builds/671013953

[hugovk]

Maybe disabling and re-enabling the Travis integration will fix it: https://twitter.com/pganssle/status/1246437422726107137

[graingert]

perhaps it would be worth switching from travis to github actions?

[hugovk]

Please see PR https://github.com/testing-cabal/testtools/pull/290 to add testing on GHA.

[FedericoRessi]

I just found a reference to unittest2 in setup.cfg file that should be removed too.

[FedericoRessi]

Can you please have a look at differences[1] between this change and PR #295? I think you are still missing something here while #295 is up to date with master branch and it is passing CI verifications.

Cheers

[1] https://github.com/mtreinish/testtools/compare/remove-unittest2...FedericoRessi:drop-unittest2

[ssbarnea]

@mtreinish time to press the update branch.

[asears]

A warning coming up that would likely be removed after this PR.

c:\tools\anaconda3\lib\site-packages\unittest2\compatibility.py:143
  Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working

[ssbarnea]

@mtreinish Any chance to add me to the project in order to avoid these to stall even longer?

[dtantsur]

@mtreinish could you make a release with this change? The latest release is broken on Python 3.10 because of unittest2.

[mtreinish]

@dtantsur I would, but I unfortunately do not have access to the project on pypi otherwise I would have released already. I'll try to reach out to @rbtcollins and/or @jelmer and fix that so we can get the release out ahead of the 3.10 release

[dtantsur]

Great to know, thanks! FYI Fedora Rawhide has already switched to 3.10, so everything using testtools may fail to build.

[ssbarnea]

@mtreinish If you do not get an answer quickly you can raise a ticket on https://github.com/pypa/pypi-support/issues/new/choose asking to be added as owner. You can also mention me in the ticket and I will back your request. Usually pypa folks are quite fast on helping with tickets like this.

[rbtcollins]

@ssbarnea they are responsive, but they also don't take over non-orphaned projects. testtools has 5 people capable of doing releases - me; @freeekanayaka @jelmer @jml @thomir :- perhaps some are no longer interested in the project in which case they can remove themselves.

@mtreinish you're mtreinish on pypi ?

[mtreinish]

@rbtcollins yeah, that's my pypi username. (https://pypi.org/user/mtreinish/ )

[rbtcollins]

@mtreinish done