Cygwin is a free and open-source Unix-like environment and command-line interface for Microsoft Windows. It provides a Linux-like API on Windows such as UNIX sockets, fork(), threads, signals, /proc filesystem, etc. I recently merged multiple changes to fix Cygwin issues and I wrote many changes to fix the Python test suite on Cygwin (issue). If you want to try it, see instructions to build Python on Cygwin.
Python already provides Windows binaries with native Windows support on python.org (PyManager). Supporting Cygwin is mostly useful to users of the Cygwin environment. Cygwin is not Linux and is not Windows, it’s a different platform in-between. I’m not sure if it would be worth it to go further in terms of support (set up a buildbot, fix the few last tests failing on Cygwin, promote the platform to PEP 11 Tier-3).
I started to work on Cygwin support since I noticed multiple users reporting Cygwin issues and proposing fixes. If there are enough Cygwin users, maybe it would be interesting to go further in terms of support. Well. I don’t know, that’s why I’m posting my message here The latest packaged Python version in Cygwin is Python 3.12. The package has multiple downstream patches (they should no longer be needed on Python 3.16 with recent Python changes).
I also had a quick look at MinGW. I understood that it’s a toolchain to build Unix applications on Windows targeting the Windows native API. I’m not sure that it’s useful to support MinGW, since Python already supports the Windows native API (without MinGW). I also quickly gave up because the Python build failed with a lot of compiler errors.
I didn’t realize Cygwin was still used significantly, I thought most tools had moved on to mingw (I think git uses or used this at one point?) or the WSL.
One in-between unsupported and making Cygwin tiered would be to add yourself (if you are willing) as a platform expert: Experts index. I think in general it would be good to try to encourage people providing multiple patches for unsupported platforms to be added as experts if they are willing so we have a clearer picture of what platforms are used. I have dreams of adding a “community supported/unofficial” tier some day so we can enumerate where CPython is run, but that is it’s own discussion.
Last I used it (which was maybe 5 years ago, so could be out of date!) the ABI is different between MSVC and mingw/gcc binaries, so I suppose if someone wanted to embed CPython in a mingw compiled application maybe that would be an issue? But given we haven’t seen issues around it, maybe that isn’t a current use case.
With mingw-w64, you can target Microsoft’s UCRT (~= C stdlib), which means the ABI is compatible; here’s a relevant discussion issue that might be of interest. Any remaining ABI differences (up to toolchain bugs) are then confined to C++ code, where GCC and MSVC do not produce compatible things, generally speaking.
For historical interest, the website of the now-defunct mingwpy project contains a lot of interesting (though likely outdated) content about these topics, e.g. details about linking to UCRT.
The only user I still know of for Cygwin is OpenJDK for their releases (and I know at least one person involved with that who would say they wish they didn’t use it, but momentum and all).
We actually use Cygwin ourselves to build libffi for use in ctypes. I think it will run with MinGW (it just seems to need Bash for their build scripts), but haven’t invested the time to try porting it.
I agree with Victor’s initial post, Cygwin is not Windows and not Unix, which means it has all of its own issues. If people want to contribute fixes (that don’t regress other platforms), we should certainly accept them.
Given [my understanding of] how Cygwin operates (more like an integrated Linux distro, everything built together), I think we’d want encouragement/involvement from one of their maintainers to start more formally trying to support it. They may prefer to be fully downstream, rather than having to worry about us chasing their older versions while they’re looking towards newer versions.
We had a similar situation in PyInstaller a while ago. At least for us, the high bug/PR counts were more a byproduct of how easy it is to break and how easy it usually is to fix (mostly adjusting which branch of an if windows/if unix condtion it should follow) than a high user count. The download counts on PyPI stats were 50/month which is low even compared to platforms I’d consider esoteric like OpenWRT+MIPS (used by Wi-Fi routers).
We added it to CI anyway. Asides from eating CI time, it hasn’t given me any reason to regret adding it.
The MSYS2 project maintains a CPython fork that is buildable with mingw-w64 + gcc/clang. It’s currently used in MSYS2 and built on Windows, as well as in llvm-mingw where it is cross-compiled on Linux. Not saying that it should be supported, just wanted to share the information in case someone is interested in it.
msys2-runtime which is a friendly fork of cygwin, is still used significantly. There are still some small differences between msys2-runtime and cygwin, but they are mostly the same (see also: How does MSYS2 differ from Cygwin? and Move the build environment closer to Cygwin #3012). In particular, git-for-windows is based on msys2, and people who use git-bash are using msys2-runtime under the hood.
Indeed, and mingw and Cygwin are not the same thing. The former provides a Windows-native GNU build toolchain, but does not make it possible to compile arbitrary POSIX-compatible code on Windows. Cygwin does by providing a (mostly) POSIX-compatible API on top of Windows (as well as a handful of Linux-specific APIs) through its own cygwin.dll runtime library that must be linked to any software compiled for Cygwin. It’s very much its own platform in a way (the Cygwin runtime also has a few Cygwin-specific APIs of its own). A lot of software intended for unices can be compiled for Cygwin and “just work” unmodified. Sometimes a sprinkling of #ifdef __CYGWIN__ need to be patched in here and there. The Cygwin project also maintains its own fairly large package repository.
I admit I don’t know how common it is anymore though some examples were cited above, but some software, including untold amounts of commercial software, support Windows via Cygwin. It’s possible to do this without the user even noticing–you just have to bundle it with a compatible cygwin1.dll. This was the approach I took some years ago to supporting the installation of SageMath on Windows, which worked remarkably well as Sage has over 100 dependencies though is primarily Python + Cython. Unfortunately I no longer had time to maintain it and no one else stepped up. So I’m not suggesting that as a reason to formally support Cygwin (though it’s why in the past I tried to work on it).
In any case everyone who does use Cygwin have gotten be pretty well for a long time without it being an “officially” supported platform by CPython, via patching. I’m not sure whether or not it has to be officially supported–but the willingess of core developers to accept patches targeting Cygwin as long as they are not too disruptive, and Victor’s recent work on getting some of those patches in, is still a help nonetheless and will reduce the maintenance burden for Cygwin packagers wishing to continue supporting Python.
tl;dr I don’t know if it’s worth putting a ton of effort into Cygwin, but it shouldn’t be dismissed either where small wins can be made to support it.
The latest packaged Python version in Cygwin is Python 3.12. The package has multiple downstream patches (they should no longer be needed on Python 3.16 with recent Python changes).