Windows pip support #1426

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

- 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 · 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.

@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

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.

visheshrwl added 12 commits January 3, 2026 19:04

fix: Use single-line Python test in Windows workflow

c9f900c

feat: Add Python 3.14 support to Windows builds

c60ef9f

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

0c9be3c

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

7763564

- 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

39055aa

ci: Add 90-minute timeout to Windows builds

920846f

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

8f838a5

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

fa88dbe

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)

6b2e941

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

ba5b1d5

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

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Windows pip support #1426

Windows pip support #1426

Uh oh!

visheshrwl commented Jan 3, 2026 •

edited

Loading

Uh oh!

lanctot commented Jan 5, 2026

Uh oh!

lanctot commented Jan 5, 2026

Uh oh!

lanctot left a 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Windows pip support #1426

Are you sure you want to change the base?

Windows pip support #1426

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

visheshrwl commented Jan 3, 2026 •

edited

Loading