chore: fix warning on pylint 4

[henryiii]

See henryiii/flake8-errmsg#72 for details.

[henryiii]

@freakboy3742 macOS-15 iOS is timing out pretty reliably, it seems.

test/test_ios.py::test_ios_platforms[build_config0] PASSED               [ 20%]
test/test_ios.py::test_ios_platforms[build_config1] +++++++++++++++++++++++++++++++++++ Timeout ++++++++++++++++++++++++++++++++++++
~~~~~~~~~~~~~~~~~ Stack of Thread-1 (run_server) (6111260672) ~~~~~~~~~~~~~~~~~~
  File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/threading.py", line 1014, in _bootstrap
    self._bootstrap_inner()
  File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/threading.py", line 1043, in _bootstrap_inner
    self.run()
  File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/threading.py", line 994, in run
    self._target(*self._args, **self._kwargs)
  File "/Users/runner/work/cibuildwheel/cibuildwheel/.venv/lib/python3.13/site-packages/pytest_rerunfailures.py", line 466, in run_server
    conn, _ = self.sock.accept()
  File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/socket.py", line 295, in accept
    fd, addr = self._accept()
+++++++++++++++++++++++++++++++++++ Timeout ++++++++++++++++++++++++++++++++++++
RERUN                                                                    [ 40%]

[freakboy3742]

(grumble...)

This is an issue that Github is aware of, and is investigating - see actions/runner-images#12777 for details.

In cibuildwheel's case, I think the problem is that it's trying to use the default iOS simulator, which, as of right now on Github Actions, is trying to use an iPhone SE running iOS 26 - but that simulator hasn't been warmed up, the warmup process can be slow, and the timeout is the consequence. The iPhone 16e running iOS 18.5 is warmed up, and is a lot more reliable.

There's at least 3 possible fixes that I can see here:

1. Modify cibuildwheel to pick a "known good" simulator. I don't love this solution - it means cibuildwheel is playing an eternal game of whack-a-mole with CI environments and what simulators are currently "working". But, it means end users won't need to configure anything to get a working configuration.
2. Add an explicit option for "simulator selection" (CIBW_SIMULATOR_IMAGE or similar). You'd specify a string that identifies a simulator, and that string is passed down to the test runner, as appropriate. Android also has the option to pick a simulator image selector, so the same option could be used there (although the format of the value would be different).
3. Add a more generic "test environment arguments" option (CIBW_TEST_ENVIRONMENT_ARGS or similar). This is an analog of CIBW_TEST_COMMAND, but differentiates "this is how you start the test suite" from "this is how you start the thing that starts the test suite". This setting would be a superset of (2) - providing a way to specify a simulator image, but also any other setting that might be configurable in running the test runner. I don't know of any other options that are needed right now - but I guess "not knowing what you might need in future" is really the hole we're in right now.

Of those three options, (3) makes the most sense to me - any thoughts on that?

In terms of an immediate workaround; moving back to the macos-14 evidently worked; I guess it's a question of how fast we need a fix for this. If I can get a sense of the preferred fix, I can prioritise this work and have a PR for you early next week.

[joerick]

I'm also drawn to (3) - controlling the test environment is probably something other platforms are gonna want some day too.

Unfortunately we already have a test-environment, which does environment variables, like environment. I'm struggling for a name, how about test-execution or test-execution-settings? I'd like something that would extend from simulator config on ios/android to also support separate docker images on linux too, in case we decide to do that one day.