Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
IvanIsCoding opened this issue Dec 18, 2023 · 4 comments
Open
Labels
bug Something isn't working

Comments

@IvanIsCoding
Copy link
Collaborator

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

@IvanIsCoding IvanIsCoding added the bug Something isn't working label Dec 18, 2023
@woodsp-ibm
Copy link
Member

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
Copy link
Collaborator Author

IvanIsCoding commented Dec 18, 2023

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
Copy link
Member

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
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants