Skip to content
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 10 additions & 11 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -1019,8 +1019,15 @@ jobs:
fail-fast: false
matrix:
include:
- { sys: mingw64, env: x86_64 }
- { sys: mingw32, env: i686 }
- sys: mingw32
env: i686
install_mingw64_only: ""
- sys: mingw64
env: x86_64
install_mingw64_only: |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd name this "extra_install", I think, since it's there to install extra stuff. And you can leave it off on the other job, variables default to empty.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done: commit bb8a794

mingw-w64-x86_64-python-numpy
mingw-w64-x86_64-python-scipy
mingw-w64-x86_64-eigen3
steps:
- uses: msys2/setup-msys2@v2
with:
Expand All @@ -1034,15 +1041,7 @@ jobs:
mingw-w64-${{matrix.env}}-python-pytest
mingw-w64-${{matrix.env}}-boost
mingw-w64-${{matrix.env}}-catch

- uses: msys2/setup-msys2@v2
if: matrix.sys == 'mingw64'
with:
msystem: ${{matrix.sys}}
install: >-
mingw-w64-${{matrix.env}}-python-numpy
mingw-w64-${{matrix.env}}-python-scipy
mingw-w64-${{matrix.env}}-eigen3
${{ matrix.install_mingw64_only }}

- uses: actions/checkout@v4

Expand Down
4 changes: 4 additions & 0 deletions tests/env.py
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,11 @@
sys.modules["__graalpython__"].get_graalvm_version() if GRAALPY else "0.0.0"
)
GRAALPY_VERSION = tuple(int(t) for t in _graalpy_version.split("-")[0].split(".")[:3])

# Compile-time config (what the binary was built for)
PY_GIL_DISABLED = bool(sysconfig.get_config_var("Py_GIL_DISABLED"))
# Runtime state (what's actually happening now)
sys_is_gil_enabled = getattr(sys, "_is_gil_enabled", lambda: True)


def deprecated_call():
Expand Down
2 changes: 1 addition & 1 deletion tests/test_cpp_conduit.py
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@


def import_warns_freethreaded(name):
if name not in sys.modules and not getattr(sys, "_is_gil_enabled", lambda: True)():
if name not in sys.modules and not env.sys_is_gil_enabled():
with pytest.warns(
RuntimeWarning, match=f"has been enabled to load module '{name}'"
):
Expand Down
6 changes: 4 additions & 2 deletions tests/test_gil_scoped.py
Original file line number Diff line number Diff line change
Expand Up @@ -199,8 +199,10 @@ def _run_in_process(target, *args, **kwargs):
if process.exitcode is None:
assert t_delta > 0.9 * timeout
msg = "DEADLOCK, most likely, exactly what this test is meant to detect."
if env.PYPY and env.WIN:
pytest.skip(msg)
if env.WIN and env.PYPY:
pytest.xfail("[TEST-GIL-SCOPED] Windows PyPy: " + msg)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This didn't run before, now it will. Guessing that's fine?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See other comment: Note that no other code is executed after the pytest.xfail() call, differently from the marker.

elif env.MACOS and not env.sys_is_gil_enabled():
pytest.xfail("[TEST-GIL-SCOPED] macOS free-threading: " + msg)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't always fail, does it? So strict=False?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The strict flag only applies to @pytest.mark.xfail(...) (the decorator/mark form). Inline pytest.xfail() doesn't take strict at all — it immediately aborts the test and reports XFAIL. There’s no concept of XPASS in this case, so strict isn't relevant here.

To be sure I looked it up the good-old way:

https://docs.pytest.org/en/stable/how-to/skipping.html#xfail-mark-test-functions-as-expected-to-fail

Note that no other code is executed after the pytest.xfail() call, differently from the marker.

raise RuntimeError(msg)
return process.exitcode
finally:
Expand Down
Loading