Pywin32 fails in Python 3.9 embedded installation
Version: 300
I am trying to install pywin32 in a Python 3.9 x64 embedded environment (on Windows 10). Installation works, but import fails.
Steps to reproduce:
mkdir embed
unzip python-3.9.0-embed-amd64.zip embed
python -m pip install --target embed pywin32
cd embed
python
import win32api
Installing the library to a different path helps:
mkdir embed
unzip python-3.9.0-embed-amd64.zip embed
python -m pip install --target embed\lib\site-packages pywin32
cd embed
python
import site
site.addsitedir("lib/site-packages")
import win32api
That's how the --target option is designed to be used - it's not "root of the python install" but literally "the dir to install the files into".
All the other packages I needed can be installed in the root of the embedded system and work there.
So at least a notice in the installer or in the documentation would be nice. It took me quite some time figuring it out. (for one project I replaced pywin32 with a private ctypes based implementation of the (few) APIs used there)
All the other packages I needed can be installed in the root of the embedded system and work there.
Hrm - I've no idea how that works, but I'll reopen this to track it in case others have ideas.
The problem is, that most of the packages simply rely on the Python search mechanism (and load the binary files relative to the location of the Python file). Pywin32 is quite opinionated on where pywintypes.py searches for it's dlls (pywin32_system32).I am sure there was a reason for doing it the way it is done (but I don't know all possible use cases), But this mechanism breaks when you install pywin32 in the embedded root.
Did not run all that so far - just looked via python -sS on existing dirs.
Thus is it just a ModuleNotFoundError? Or is there more to "fails"?
Why is site.addsitedir(".") (or better its absolute path) not tried with 'equal rights'? Maybe that does it - like here in that sim? Including pywintypes dll ?
The pywin32.pth provides the search paths for all of the pywin32 stuff, which I think a valid thing. And that is not evaluated unless a custom unpack to a random directory (incl. that of python.exe) is added to site dirs.
If simple packages don't add paths, you may have had luck.
There is yet good reason to use the default structure like <embed>/lib/site-packages. Deviating may naturally require extra care. (Pythonwin.exe would perhaps not find python dll without further links then)
If pywintypes and pythoncom dlls are required in system32 also because of COM server or so consider the postinstall script - elevated.
This issue recurred for python 3.8, 3.9.. I didn't try other versions My fix for this issue
- Add below paths to
python39._pth
.\Lib\site-packages
.\Lib\site-packages\win32
.\Lib\site-packages\win32\lib
.\Lib\site-packages\win32ctypes\pywin32
.\Lib\site-packages\win32ctypes
.
- Run
.\python.exe .\Scripts\pywin32_postinstall.py -installorcp .\Lib\site-packages\pywin32_system32\*.dll .\
I encounter the same issues (in our CI on Windows with Python 3.9). It's not pip installable seemingly, so I think this should somehow be fixed? It's a dependency of a dependency, so we do not have really control over it's installation (or care about)
I do not understand enough of the internals, unfortunately.
I encounter the same issues (in our CI on Windows with Python 3.9). I
That looks like a problem with a package called pywin32-ctypes, which is not associated with pywin32 and I don't recall ever having heard of it.
Indeed, sorry for the noise and thanks for spotting!