The Windows wheels published since 3.3.1 link the C++ runtime dynamically, so _greenlet.pyd imports MSVCP140.dll. Up to and including 3.3.0 it imported nothing beyond KERNEL32.dll and the Python DLL.
Import tables read from the published cp312-win_amd64 wheels:
| release |
greenlet/_greenlet.cp312-win_amd64.pyd imports |
| 3.2.4 |
KERNEL32.dll, python312.dll |
| 3.3.0 |
KERNEL32.dll, python312.dll |
| 3.3.1 |
the above plus MSVCP140.dll, VCRUNTIME140.dll, VCRUNTIME140_1.dll, api-ms-win-crt-* |
| 3.3.2 through 3.5.4 |
same as 3.3.1 |
No Windows CPython distribution ships MSVCP140.dll. The python.org embeddable package and the python-build-standalone builds that uv installs both carry vcruntime140.dll and vcruntime140_1.dll and nothing further. On a machine without the Visual C++ 2015-2022 redistributable, importing greenlet therefore fails with
ImportError: DLL load failed while importing _greenlet: The specified module could not be found.
This looks like an oversight in #490. appveyor.yml set GREENLET_STATIC_RUNTIME: "1", which setup.py still honours by adding /MT. That file went away with the move to GHA, and the workflow step that replaced it does not set the variable.
It reaches people who never touch greenlet directly. playwright imports it unconditionally from _impl/_connection.py, including on the async-only path, so uvx-installed tools that depend on playwright fail at startup on Windows machines without the redistributable. That is how I ran into it: stickerdaniel/linkedin-mcp-server#688.
PR follows.
The Windows wheels published since 3.3.1 link the C++ runtime dynamically, so
_greenlet.pydimportsMSVCP140.dll. Up to and including 3.3.0 it imported nothing beyondKERNEL32.dlland the Python DLL.Import tables read from the published
cp312-win_amd64wheels:greenlet/_greenlet.cp312-win_amd64.pydimportsKERNEL32.dll,python312.dllKERNEL32.dll,python312.dllMSVCP140.dll,VCRUNTIME140.dll,VCRUNTIME140_1.dll,api-ms-win-crt-*No Windows CPython distribution ships
MSVCP140.dll. The python.org embeddable package and the python-build-standalone builds thatuvinstalls both carryvcruntime140.dllandvcruntime140_1.dlland nothing further. On a machine without the Visual C++ 2015-2022 redistributable, importing greenlet therefore fails withThis looks like an oversight in #490.
appveyor.ymlsetGREENLET_STATIC_RUNTIME: "1", whichsetup.pystill honours by adding/MT. That file went away with the move to GHA, and the workflow step that replaced it does not set the variable.It reaches people who never touch greenlet directly. playwright imports it unconditionally from
_impl/_connection.py, including on the async-only path, souvx-installed tools that depend on playwright fail at startup on Windows machines without the redistributable. That is how I ran into it: stickerdaniel/linkedin-mcp-server#688.PR follows.