Windows installation via pip/PyPI support in beta

[lanctot]

Hi all!

I'm super excited to annonce that today's release of OpenSpiel 1.6.13 includes Windows support! 🎉

Thanks to the amazing contribution of @visheshrwl 👍 👍 👍 Windows wheels have now been built and uploaded to PyPI for Python versions 3.11, 3.12, 3.13, and 3.14. So, they should be available directly via pip install open_spiel on Windows. For more detail, please see the Windows installation instructions.

Please be warned that is was lightly tested on Github Actions and is still in a beta phase. If you have a Windows machine, we would love some volunteer testers. All feedback is welcome. Please let's use this thread for any questions or issues that come up. Ideally, we will fix everything before the release of OpenSpiel 2.0. Thanks and enjoy!

[visheshrwl]

Bug 1 - spawn.py crashes on import on Windows

File: open_spiel/python/utils/spawn.py

Fix: PR #1532

multiprocessing.set_start_method("fork") raises ValueError on Windows because "fork" is not a supported start method there (only "spawn" and "forkserver" exist). The original except RuntimeError clause, added for macOS/Python 3.8 compatibility, does not catch this, so the module fails to import entirely on Windows.

Before

except RuntimeError:

After

except (RuntimeError, ValueError):  # ValueError on Windows, RuntimeError if already set

On Windows the exception is caught, the call is silently skipped, and multiprocessing continues with its default "spawn" method, which is fully functional. Linux and macOS behaviour is unchanged.

Bug 2 — Example scripts fail on Windows due to hardcoded /tmp/ paths

Files: 15 example scripts across open_spiel/python/examples/, open_spiel/python/mfg/examples/, and open_spiel/python/voting/examples/

Fix: PR #1533

Fifteen example scripts use /tmp/... as hardcoded default paths for checkpoint directories, output files, and temporary databases. /tmp/ does not exist on Windows; these paths raise FileNotFoundError or OSError at startup before any game logic runs.

Uniform fix applied to all 15 files:

Before

flags.DEFINE_string("checkpoint_dir", "/tmp/dqn_test", ...)

After

import os, tempfile
flags.DEFINE_string("checkpoint_dir", os.path.join(tempfile.gettempdir(), "dqn_test"), ...)
tempfile.gettempdir() 

returns the correct platform temp directory (C:\Users...\AppData\Local\Temp on Windows, /tmp on Linux, system temp on macOS).

On Linux and macOS the behaviour is identical to before; on Windows the examples now start correctly.

[alexunderch]

Also, orbax checkpointing used for jax API might be incompatible with Windows: google/orbax#2914

I don't personally think that these issues need to be fixed as of now, they have to be addressed, because we need to, first and foremost, make the tests run on windows. Current CI pipeline is unreliable for anything other than import pyspiel.

[lanctot]

Thanks @visheshrwl ! I agree with @alexunderch ; we don't need to offer full Windows support across all the files. In particular, these are used during training. Training will always require customization of some form based on one's local setup, so it's not really a big deal that some parts of hard-coded for Linux use cases. I will keep importing anything of this style, but we definitely do not need to provide such a high level of cross-platform support (i.e. beyond the core library and games).

[alexunderch]

@visheshrwl for a couple hours of manual cherry-picked testing, I've found like 10x more issues than you've described above. Therefore, if you want to make the algorithms work on Windows, you need to make the test set pass. It's not a one day job, istg. Thus, depending on your ambition, you can propose a roadmap, how to organise the CI process in a cross-platform manner.

I am sure that Dr. Lanctot would be glad to have that done in the future versions, but he is alone and he must approve everything we do to make sure that it'll the library stays usable. Thank you for the work, you've been doing 😄 ❤️

[alexunderch]

btw @visheshrwl I've noticed that we do pip install thingy for the library, but do we install globally or to a venv? If the former, can we avoid that, if possible, as it was done in the linux/mac installs?

[visheshrwl]

@alexunderch the Windows CI currently installs globally while Linux/Mac uses a venv. I'll fix this by creating a venv and adding it to GITHUB_PATH at the start of the Windows job so it persists across all steps, consistent with the Linux/Mac workflow.

[alexunderch]

@visheshrwl I have been making a PR with the documentation correction: #1534

can you, please, contribute to it, comment what to add, just to not overproduce PRs. Appreciate it