Add cp314t build

[bashtage]

closes#208

[rgommers]

The 3.14t-specific failures on macOS, Linux and x86-64 Windows are all the same:

 ================================== FAILURES ===================================
_________________ test_negative_binomial_default_alpha_param __________________
[gw1] win32 -- Python 3.14.5 C:\Users\runneradmin\AppData\Local\Temp\cibw-run-23n5l6d3\cp314t-win_amd64\venv-test\Scripts\python.exe
def test_negative_binomial_default_alpha_param():
with pytest.warns(
UserWarning, match="Negative binomial dispersion parameter alpha not set"
):
sm.families.NegativeBinomial()
with pytest.warns(
UserWarning, match="Negative binomial dispersion parameter alpha not set"
):
sm.families.NegativeBinomial(link=sm.families.links.NegativeBinomial(alpha=1.0))
with warnings.catch_warnings():
warnings.simplefilter("error")
> sm.families.NegativeBinomial(alpha=1.0)
..\venv-test\Lib\site-packages\statsmodels\discrete\tests\test_discrete.py:2681: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <statsmodels.genmod.families.family.NegativeBinomial object at 0x0000026651B65290>
link = None, alpha = 1.0, check_link = True
def __init__(self, link=None, alpha=1.0, check_link=True):
self.alpha = 1.0 * alpha # make it at least float
if alpha is self.__init__.__defaults__[1]: # `is` is intentional
> warnings.warn(
"Negative binomial dispersion parameter alpha not "
f"set. Using default value alpha={alpha}.",
ValueWarning,
stacklevel=2,
)
E statsmodels.tools.sm_exceptions.ValueWarning: Negative binomial dispersion parameter alpha not set. Using default value alpha=1.0.

That seems relatively benign, and is possibly related to the different default for warnings behavior under free-threading: https://docs.python.org/3.14/whatsnew/3.14.html#concurrent-safe-warnings-control.

The Windows on Arm jobs show crashes, but on all of cp313, cp314 and cp314t jobs. May be useful to try to diagnose one of the GIL-enabled builds first, and then see if anything is left.

https://github.com/MacPython/statsmodels-wheels/actions/runs/27669875530/job/81831635348?pr=212

[bashtage]

The windows arm failures are expected. They have been failing since they were first started. There appears to be OpenBlas bug(s). These have been reported to NumPy.

I agree that the warnings failure is pretty important. The bigger issue is that other parts segfault under free threading when actually run in parallel. But I suppose we can still have a cp314t wheel even if it isn't actually threadsafe.

[kumaraditya303]

The bigger issue is that other parts segfault under free threading when actually run in parallel. But I suppose we can still have a cp314t wheel even if it isn't actually threadsafe.

The statespace tests segfault when run in parallel because the testa are written in an unsafe way. The class TestDynamicFactor shares a single model across multiple threads and when tests call filter on it in test_params it crashes. Fixing this would require porting all of those tests to keep the model either thread local or create fresh model for each thread.

[bashtage]

I'm happy with more models. Cold you point me to an example where a model is shared? I'm happy to use some tokens to tackle this.

[kumaraditya303]

I'm happy with more models. Cold you point me to an example where a model is shared? I'm happy to use some tokens to tackle this.

See https://github.com/statsmodels/statsmodels/blob/cfae27cdd96c2fda81eeac682308092432d211eb/statsmodels/tsa/statespace/tests/test_dynamic_factor.py#L28-L63 During the setup of test it assigns a model to a cls.model which gets used concurrently by all threads. The test_params test also modifies the model by changing enforce_stationarity which also needs to be fixed.

[kumaraditya303]

I submitted statsmodels/statsmodels#9877 to fix the test_negative_binomial_default_alpha_param failures.

[bashtage]

@copilot please fix the merge conflicts in this pull request.

[bashtage]

I have spent a bit of time getting the test suite to pass on a multi threaded run. The exercise shows that statsmodels is not really threadsafe. There are some pretty agregious practices like adding an attribute during fit() and the calling del to remove it before returning. State space is also not close to threadsafe, which isn't hugely surprising, and would need to add Lock()s to get close

[Copilot]

Pull request overview

This PR updates the wheel-build GitHub Actions workflow to include CPython 3.14 free-threaded (cp314t) artifacts, aligning with issue #208’s goal of publishing cp314t wheels to PyPI.

Changes:

• Add cp314t to the cibuildwheel build matrix.
• Switch the Pyodide build target from cp312 to cp313 and explicitly constrain Pyodide builds to cp313-*.
• Adjust CIBW_SKIP patterns (dropping the pp*/PyPy skip).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

.github/workflows/build-wheels.yml:42

• The env block comments state there is no support for PyPy, but CIBW_SKIP no longer skips pp*. This makes the workflow configuration internally inconsistent and could allow accidental PyPy builds if CIBW_BUILD is broadened later. Either restore the PyPy skip (as before) or update the comments to match the intended behavior.

 # No support for pypy, musl, Win32 for 3.10+
# Skip musl for 3.8 and 3.9 since no upstream wheels
CIBW_SKIP: "*-win32 *musllinux_aarch64*"

[bashtage]

This is going in - will now have overnight cp314t wheels. Thanks for the help.