Windows pip support by visheshrwl · Pull Request #1426 · google-deepmind/open_spiel

visheshrwl · 2026-01-03T13:51:29Z

feat: Add Windows pip installation support

Add setup.py with CMake extension building and dependency auto-cloning
Add pyproject.toml for modern Python packaging
Add GitHub Actions CI/CD for automated wheel building
Add WINDOWS_INSTALL.md guide and test_installation.py validator
Transform complex manual Windows setup to simple 'pip install open-spiel'
Fix CMake configuration for proper pyspiel.pyd placement
Update README.md with Windows installation documentation
Enables native Windows pip installation, eliminating 20+ manual setup steps

lanctot · 2026-01-05T00:54:39Z

Hi @visheshrwl , does this replace #1422 ?

lanctot · 2026-01-05T01:02:36Z

@visheshrwl

I'm quite impressed that you got this to work! It's been a major feature request for the past 3 years. However, there is one thing we need to discuss before I take a deeper look ifwe import this and "officially" support Windows OpenSpiel via pip.

We unfortunately don't have resources to properly support Windows (without external help). If we put up Windows pip wheels and distribute them on PyPI, that could means a spike in usage on the Windows platform and could bring about some bugs or other issues we haven't seen before. It could also lead to breakage in the future as the code changes.

Would you be willing to help fix things in the Windows wheels if/when they break?

lanctot

Where is test_installation.py used?

.github/workflows/build-wheels.yml

pyproject.toml

visheshrwl · 2026-01-05T04:28:41Z

Where is test_installation.py used?

It's a standalone script I used for local Windows testing. It’s not part of any workflow and will be removed in the next PR.

visheshrwl · 2026-01-05T04:37:00Z

@visheshrwl

I'm quite impressed that you got this to work! It's been a major feature request for the past 3 years. However, there is one thing we need to discuss before I take a deeper look ifwe import this and "officially" support Windows OpenSpiel via pip.

We unfortunately don't have resources to properly support Windows (without external help). If we put up Windows pip wheels and distribute them on PyPI, that could means a spike in usage on the Windows platform and could bring about some bugs or other issues we haven't seen before. It could also lead to breakage in the future as the code changes.

Would you be willing to help fix things in the Windows wheels if/when they break?

Hi @lanctot,

Thank you for the kind words! I'm glad I could help solve this long-standing feature request.

I absolutely understand the concern about supporting Windows long-term. Yes, I'm willing to help maintain the Windows wheels. Here's what I can commit to:

What I can do:

Monitor and fix Windows-specific build/CI failures
Debug Windows wheel issues and respond to bug reports
Keep the Windows build configuration updated as dependencies evolve
Document Windows-specific quirks or limitations

Response times:

Critical CI failures: I aim to address these within 48-72 hours
User-reported issues: within a week for investigation
Non-urgent improvements: as time permits

What would help me help you:

Tagging me on Windows-related issues
Being notified of major dependency/build system changes
Access to Windows CI logs when failures occur

Limitations:

I'm contributing as a community member, so there may be occasional delays during busy periods
For issues beyond Windows wheels (e.g., game logic bugs that just happen to appear on Windows first), I may need help from the core team

I think it would also be wise to document in the installation guide that Windows support is "community-maintained" to set appropriate user expectations.

I see this as a valuable opportunity to contribute to a project I use and learn from the codebase. I'm committed to keeping this working long-term.

Does this level of commitment work for you?

lanctot · 2026-01-05T12:49:37Z

Great, and yes that works for us, thank you!

Does this PR replace #1422?

Quick question: have you tried using the resulting wheels via a pip install on Windows? Can we please add some documentation on how to do that (via a new section at the very top of windows.md)? Once it's on PyPI will it be as simple as running pip install open-spiel like MacOS and Linux?

You don't need to make a new PR each time you make changes btw, just commit + push to this branch.

visheshrwl · 2026-01-05T13:49:57Z

Quick question: have you tried using the resulting wheels via a pip install on Windows? Can we please add some documentation on how to do that (via a new section at the very top of windows.md)? Once it's on PyPI will it be as simple as running pip install open-spiel like MacOS and Linux?

Yes, the Windows wheels were tested via pip install on Windows using the Python launcher. Once uploaded to PyPI, installation will be identical to macOS and Linux (pip install open-spiel), provided users use the standard python.org Python distribution.

Does this PR replace #1422?

The code in #1426 is the refined, up-to-date version implementing Windows pip/wheel support.

lanctot · 2026-01-13T01:20:14Z

Hi @visheshrwl, sorry to ask one more time but it'll be the last time, promise!

We just removed support for Python 3.10 in #1424 (we had to do this today, there were a number of problems and CI tests were failing because of it), so we merged into master today. There are likely going to be conflicts with this PR as a result. Oh it looks like only one file.. maybe not so bad after all.

Could you pull changes from master and either rebase or push a merge commit?

(Also please remove any tests based on Python 3.10)

Once done, as long as tests pass, I'll finally take a look and pull this in! Thanks for your patience.

visheshrwl · 2026-01-13T06:17:05Z

Hi @visheshrwl, sorry to ask one more time but it'll be the last time, promise!

We just removed support for Python 3.10 in #1424 (we had to do this today, there were a number of problems and CI tests were failing because of it), so we merged into master today. There are likely going to be conflicts with this PR as a result. Oh it looks like only one file.. maybe not so bad after all.

Could you pull changes from master and either rebase or push a merge commit?

(Also please remove any tests based on Python 3.10)

Once done, as long as tests pass, I'll finally take a look and pull this in! Thanks for your patience.

Hi @lanctot ,

No worries at all! I've just completed the udpates.
The branch should now merge cleanly. Tests should pass with the changes.

Thanks for your patience as well!

lanctot · 2026-01-13T10:31:46Z

We have to keep the new style of MutexLock (without the ampersand); these were all modified in #1424

You might need to adjust an abseil version to a newer one in one of the tests, see #1424

.github/workflows/build-wheels.yml

open_spiel/spiel.h

lanctot · 2026-01-13T13:22:21Z

It appears you and @alexunderch are running into the same issue (he's working on #1408).

I suspect the arm64 wheels are broken due to the scipy upgrade from a few days ago.

Can you comment out the arm64 test in wheels.yml for now to see if it works?

Also revert the yum commands

.github/workflows/wheels.yml

lanctot · 2026-01-13T13:24:49Z

visheshrwl

Confirmed: https://github.com/google-deepmind/open_spiel/actions/runs/20957953304/job/60227228831

alexunderch · 2026-01-13T13:53:20Z

Yes, we need to tackle ARM is a separate PR, because it's not as simple as it looks. Moreover, that ARM test doesn't actually run Ubuntu, it's either centos or fedora, so the wheels need to be addressed a bit differently.

lanctot · 2026-01-13T22:49:03Z

@visheshrwl thanks to the awesome work by @alexunderch the master branch is finally all fixed up and all the tests are now working. Feel free to merge into your branch or re-open a new PR with these changes. We still want them.. it's just been a rather chaotic few days re: stability. :)

lanctot · 2026-01-13T22:50:05Z

The original PR you had working as of two days ago should work with the state of master currently. Sorry for the unfortunate timing!

lanctot · 2026-01-17T01:02:37Z

@visheshrwl just checking to see if you plan to reopen or resubmit?

visheshrwl · 2026-01-18T04:41:14Z

@lanctot Thanks for reaching out and for the heads-up on the master branch! I definitely want to get this resubmitted. I’m currently in the middle of a massive 1,700km move for a new job, so I just need a few days to get my setup back online. I'll get an update to you shortly.
Thanks for sticking with me while I get settled!

lanctot · 2026-01-18T04:45:49Z

Oh wow, I have done one of those.. totally hear you.

Thanks for the update and no rush. Just wanted to be sure you get the credit for it. :)

alexunderch · 2026-01-18T12:16:18Z

@visheshrwl hey after you finish, ping me thereafter

current checkpointing protocols I implement, should trustrably work only with posix paths/fs, so maybe some adjustments or clarifications will be needed

thank you in advance

- Add setup.py with cross-platform CMake extension building - Add pyproject.toml for modern Python packaging (PEP 517) - Add GitHub Actions CI for automated Windows wheel building (py3.10-3.13) - Add WINDOWS_INSTALL.md guide and test_installation.py validator - Transform complex manual Windows setup to simple 'pip install open-spiel' - Fix dynamic wheel selection in test_wheel.sh for all Python versions - Update README.md with Windows installation documentation - Set python_requires>=3.10 to match upstream Enables native Windows pip installation, eliminating 20+ manual setup steps Resolves google-deepmind#804

- Use cmake --build with MSVC on Windows instead of make - Add Windows compiler flags (/std:c++17 /utf-8 /bigobj) - Skip C++ compiler check on Windows (CMake handles it) - Keep Unix build path unchanged (clang++/make)

Upstream skips Python 3.13 testing on macos-15 due to a known issue in rcfr_pytorch_test.py with NumPy strict type checking in Python 3.13. Reverting to upstream behavior to keep PR focused on Windows pip support.

Restore upstream behavior where macOS Python 3.13 runner skips full tests since only Python 3.14 wheel is built. This matches the upstream workaround for Python 3.13 compatibility issues.

Changed hardcoded manylinux_2_17_x86_64 pattern to wildcard manylinux* to support both x86_64 and aarch64 (ARM64) wheel architectures.

- Move pip installation instructions from WINDOWS_INSTALL.md to docs/windows.md as Option 1 - Remove WINDOWS_INSTALL.md (content now in docs/windows.md) - Remove Windows install link from README.md (already linked from docs/install.md) - Remove unnecessary root __init__.py (open_spiel/__init__.py already exists) Addresses feedback from code review.

@lanctot

- Update GitHub Actions to v6 (checkout@v6, setup-python@v6) - Add missing core dependencies to pyproject.toml (scipy, ml-collections) - Match version constraints from requirements.txt - Remove unused test_installation.py Addresses: @lanctot's review comments

- Add setup.py with cross-platform CMake extension building - Add pyproject.toml for modern Python packaging (PEP 517) - Add GitHub Actions CI for automated Windows wheel building (py3.10-3.13) - Add WINDOWS_INSTALL.md guide and test_installation.py validator - Transform complex manual Windows setup to simple 'pip install open-spiel' - Fix dynamic wheel selection in test_wheel.sh for all Python versions - Update README.md with Windows installation documentation - Set python_requires>=3.10 to match upstream Enables native Windows pip installation, eliminating 20+ manual setup steps Resolves google-deepmind#804

Upstream skips Python 3.13 testing on macos-15 due to a known issue in rcfr_pytorch_test.py with NumPy strict type checking in Python 3.13. Reverting to upstream behavior to keep PR focused on Windows pip support.

…clude scipy for ARM64

…blas-devel

…documentation

lanctot · 2026-01-19T19:11:21Z

.github/workflows/build-wheels.yml

@@ -0,0 +1,87 @@
+name: Build Wheels (Windows)


can we rename this file to build-wheels-windows.yml?

lanctot · 2026-01-19T19:11:58Z

.github/workflows/wheels.yml

-# tests (tests that use extra dependencies such as PyTorch, JAX, Tensorflow)
-# are tested in the Github Actions CI environment (Ubuntu 20.04 and Mac OS
-# 10.15).
+# Each wheel is built via the manylinux2014 pypa Docker image on Linux,


I think this has changed now to a more recent docker image, can we update this comment?

lanctot · 2026-01-19T19:12:31Z

.github/workflows/wheels.yml

-          CIBW_ENABLE: all
-          CIBW_ENVIRONMENT: "CXX=$(which g++) OPEN_SPIEL_BUILDING_WHEEL='ON' OPEN_SPIEL_BUILD_WITH_ACPC='ON' OPEN_SPIEL_BUILD_WITH_HANABI='ON' OPEN_SPIEL_BUILD_WITH_ROSHAMBO='ON'"
-          CIBW_BUILD: cp311-manylinux_aarch64 cp312-manylinux_aarch64 cp313-manylinux_aarch64 cp314-manylinux_aarch64
+        # Temporarily disabled due to scipy compatibility issues


These have now been re-enabled.

Can you pull recent changes from master and commit a merge or rebase?

lanctot · 2026-01-19T19:14:25Z

test_installation.py

@@ -0,0 +1,29 @@
+#!/usr/bin/env python3


Can we move this file into python/tests?

lanctot · 2026-01-19T19:16:35Z

README.md

 Please choose among the following options:

 *   [Installing OpenSpiel](docs/install.md)
+*   **[Windows Installation (pip install)](WINDOWS_INSTALL.md)**


Can we make this this a subsection of the already-existing windows.md ?

(Make it the top one, though.. leaving the build from source ones to further down.)

lanctot · 2026-01-19T19:18:47Z

.github/workflows/wheels.yml

            dist/*.tar.gz
            ./wheelhouse/*.whl

+  # Windows wheel builds - separate job due to different build process (no cibuildwheel)


Really? no cibuildwheel? I'm surprised, it said it supported Windows.

Fine with me, though, if this works..

lanctot · 2026-01-19T19:19:38Z

.github/workflows/wheels.yml

+          python -c "import pyspiel; game = pyspiel.load_game('tic_tac_toe'); print('OpenSpiel works! Game:', game.get_type().short_name)"
+        shell: pwsh
+
+      - name: Run basic tests


Maybe add a commet here that the windows tests are less thorough. Maybe we can improve this down the road.

lanctot · 2026-01-19T19:21:11Z

WINDOWS_INSTALL.md

@@ -0,0 +1,104 @@
+# OpenSpiel Windows Installation Guide
+


Can we add something here that indicates it's currently experimental and encourage users to open an issue if there are any problems? Thanks.

lanctot requested changes Jan 5, 2026

View reviewed changes

.github/workflows/build-wheels.yml Outdated Show resolved Hide resolved

.github/workflows/build-wheels.yml Outdated Show resolved Hide resolved

pyproject.toml Outdated Show resolved Hide resolved

lanctot mentioned this pull request Jan 5, 2026

Feat: Add native Windows pip installation support with automated CI/CD #1369 #1422

Closed

visheshrwl requested a review from lanctot January 6, 2026 13:44

lanctot reviewed Jan 13, 2026

View reviewed changes

.github/workflows/build-wheels.yml Outdated Show resolved Hide resolved

open_spiel/spiel.h Outdated Show resolved Hide resolved

lanctot mentioned this pull request Jan 13, 2026

Deep cfr jax refactor #1408

Closed

lanctot reviewed Jan 13, 2026

View reviewed changes

.github/workflows/wheels.yml Outdated Show resolved Hide resolved

visheshrwl force-pushed the windows-pip-support branch from 8e300db to c8db4a7 Compare January 13, 2026 13:49

visheshrwl closed this Jan 13, 2026

visheshrwl force-pushed the windows-pip-support branch from 8e300db to 76ca30e Compare January 13, 2026 14:00

visheshrwl added 3 commits January 19, 2026 10:41

fix: Use single-line Python test in Windows workflow

f7aeaab

feat: Add Python 3.14 support to Windows builds

7e811cd

visheshrwl added 22 commits January 19, 2026 10:42

fix: Build cp313 wheel on macOS-15 runner to match test Python version

371cf0e

fix: Add Windows-specific CMake build configuration to setup.py

c6f8538

- Use cmake --build with MSVC on Windows instead of make - Add Windows compiler flags (/std:c++17 /utf-8 /bigobj) - Skip C++ compiler check on Windows (CMake handles it) - Keep Unix build path unchanged (clang++/make)

fix: Clone json without --depth to allow checkout of specific commit

e73327f

ci: Add 90-minute timeout to Windows builds

1a31344

fix: Use PowerShell for Windows wheel install and add build validation

e12d3b5

revert: Match upstream by only building cp314 on macos-15

d216800

Upstream skips Python 3.13 testing on macos-15 due to a known issue in rcfr_pytorch_test.py with NumPy strict type checking in Python 3.13. Reverting to upstream behavior to keep PR focused on Windows pip support.

fix: Skip full tests on macOS Python 3.13 (only cp314 wheel built)

01b065b

Restore upstream behavior where macOS Python 3.13 runner skips full tests since only Python 3.14 wheel is built. This matches the upstream workaround for Python 3.13 compatibility issues.

fix: Support both x86_64 and aarch64 Linux wheels in test script

6f68bf1

Changed hardcoded manylinux_2_17_x86_64 pattern to wildcard manylinux* to support both x86_64 and aarch64 (ARM64) wheel architectures.

fix: Build cp313 wheel on macOS-15 runner to match test Python version

9a5885f

revert: Match upstream by only building cp314 on macos-15

b5f5ca5

Upstream skips Python 3.13 testing on macos-15 due to a known issue in rcfr_pytorch_test.py with NumPy strict type checking in Python 3.13. Reverting to upstream behavior to keep PR focused on Windows pip support.

docs: Update Windows documentation to require Python 3.11+

11aeaa0

fix: correct mutex lock initialization in Game class

3b7e2a4

fix: update mutex lock initialization in Game class

aa8199e

fix: update basic mode dependency installation in test_wheel.sh to in…

8124d65

…clude scipy for ARM64

fix: adjust scipy installation for ARM64 in basic mode of test_wheel.sh

74336b9

fix: update CIBW_BEFORE_ALL_LINUX to install epel-release before open…

21139a2

…blas-devel

fix: temporarily disable ARM64 build due to scipy compatibility issues

d2761c0

fix: simplify basic mode dependency installation in test_wheel.sh

1435f2e

fix: update GitHub Actions workflows for Windows support and improve …

c5f7ef3

…documentation

visheshrwl reopened this Jan 19, 2026

lanctot requested changes Jan 19, 2026

View reviewed changes

Merge branch 'google-deepmind:master' into windows-pip-support

f1c92a3

Comments

Conversation

visheshrwl commented Jan 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lanctot commented Jan 5, 2026

Uh oh!

lanctot commented Jan 5, 2026

Uh oh!

lanctot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

visheshrwl commented Jan 5, 2026

Uh oh!

visheshrwl commented Jan 5, 2026

Uh oh!

lanctot commented Jan 5, 2026

Uh oh!

visheshrwl commented Jan 5, 2026

Uh oh!

lanctot commented Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

visheshrwl commented Jan 13, 2026

Uh oh!

lanctot commented Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lanctot commented Jan 13, 2026

Uh oh!

Uh oh!

lanctot commented Jan 13, 2026

Uh oh!

alexunderch commented Jan 13, 2026

Uh oh!

lanctot commented Jan 13, 2026

Uh oh!

lanctot commented Jan 13, 2026

Uh oh!

lanctot commented Jan 17, 2026

Uh oh!

visheshrwl commented Jan 18, 2026

Uh oh!

lanctot commented Jan 18, 2026

Uh oh!

alexunderch commented Jan 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

visheshrwl commented Jan 3, 2026 •

edited

Loading

lanctot commented Jan 13, 2026 •

edited

Loading

lanctot commented Jan 13, 2026 •

edited

Loading