Switch from unittest to stestr runner after Windows 3.12 bug is fixed

[IvanIsCoding]

Information

• rustworkx version: main
• Python version: 3.12
• Rust version: Stable
• Operating system: Windows

What is the current behavior?

The test passes when running with python -m unittest discover and fail with stestr run. This indicates a possible issue with the test runner

Steps to reproduce the problem

Compare the result of this Github Action: https://github.com/Qiskit/rustworkx/actions/runs/7243374909
Against this Github Action: https://github.com/Qiskit/rustworkx/actions/runs/7243502875

It looks like skipped tests are failing stestr in Windows with Python 3.12

[woodsp-ibm]

I had noticed a similar failure in recent qiskit algorithms nightly builds - e.g here https://github.com/qiskit-community/qiskit-algorithms/actions/runs/7242612061/job/19728274840 One difference I had noticed is that when it ran ok it was Python 3.12.0 and when it started failing it was 3.12.1 in the log messages. I had looked at stestr, since that is used there too, but it has not been updated in some while. I had not investigated further

[IvanIsCoding]

I had noticed a similar failure in recent qiskit algorithms nightly builds - e.g here https://github.com/qiskit-community/qiskit-algorithms/actions/runs/7242612061/job/19728274840 One difference I had noticed is that when it ran ok it was Python 3.12.0 and when it started failing it was 3.12.1 in the log messages. I had looked at stestr, since that is used there too, but it has not been updated in some while. I had not investigated further

It could be an issue with Python 3.12.1 and one of the stestr or its dependencies. Minor versions shouldn’t break like this but out of all libraries that use undocumented behaviour from Python, I think this is one of the most likely cases

[mtreinish]

FWIW, this was a breaking api change made in Python 3.12.1's unittest module (which IMO was inappropriate for backporting in a stable point release, but there's no arguing with it now). I pushed up: testing-cabal/testtools#371 which I think should fix it, but the failure mode I was fixing in that PR was slightly different from what's in the failure logs. But I expect it's the same root cause.

[IvanIsCoding]

FWIW, this was a breaking api change made in Python 3.12.1's unittest module (which IMO was inappropriate for backporting in a stable point release, but there's no arguing with it now). I pushed up: testing-cabal/testtools#371 which I think should fix it, but the failure mode I was fixing in that PR was slightly different from what's in the failure logs. But I expect it's the same root cause.

We can try it again after the fix is released. Currently the default runner is working well enough for GitHub CI so there is no rush