Any plan to support WSL?

[ajkessel]

trafficstars

Is there any plan/ability to support WSL? The module installs fine from Python in WSL but complains ImportError: cannot import name 'COMError' from '_ctypes' on import.

Same issue in Cygwin which presumably has even more direct access to COM?

[junkmd]

Hi, @ajkessel

This package functionalities depends on Python being the Windows version.

This package cannot be executed with the Linux version of Python, including that operates on WSL.

Cygwin performs API translation to utilize the Windows kernel, whereas WSL uses the Linux kernel itself. Although, to my knowledge, the Python available in Cygwin is the Windows version.

This package does not cause an error upon installation itself to platforms other than Windows, as it may be specified as a dependency for cross-platform compatible software. There was a report in issue #157 that installing this package in a Linux environment caused an error, but this has been corrected since 1.1.7.

I have come to think that the content written in the "Frequently Asked Questions" is insufficient. It seems necessary to clearly state that "while this package can be installed on other platforms, it is only executable with the Windows version of Python" after the note for cross-platform.

Have you actually run comtypes from Cygwin?

[ajkessel]

cygwin also fails

ImportError: cannot import name 'COMError' from '_ctypes' (/usr/lib/python3.9/lib-dynload/_ctypes.cpython-39-x86_64-cygwin.dll)

I think there are probably other users like me (not especially sophisticated) who think of WSL applications as having some "Windows-like" properties even if it is, in fact, a Linux distribution. I did some poking around and couldn't figure out if the COM interface is actually exposed to WSL, but it is possible, e.g., to run Windows binaries from the command-line in WSL and it works seamlessly with native WSL components.

[junkmd]

I would like you to show us what sys.platform in your cygwin Python environment returns.

Perhaps this issue should be escalated to the cpython community that implements ctypes and _ctypes.

[junkmd]

I realized that there might have been some mistakes in the knowledge I had.

Since the Cygwin version of Python (even though the source code is common) is not an official build of CPython, escalating Cygwin's circumstances to the CPython community might be inappropriate.

Since Cygwin can execute Windows exe files, by running the python.exe in the virtual environment created with the Windows version of Python, you might be able to achieve what you want.

Please try it in your environment and share it with this community.

[ajkessel]

sys.platform in cygwin python reports cygwin.

I'll see what I can figure out using the Windows python.exe from within WSL/cygwin.

[ajkessel]

OK, this does what I want, and works in WSL and cygwin. Comtypes (and the uiautomation library) work fine when python is invoked this way.

I created a script we'll call activate which can be sourced in either Linux-like environment to remap python to Windows Python within my venv. Of course, you could just map python to python.exe if you didn't care about venv. And the export WSLENV line is only necessary for WSL.

export OLD_VIRTUAL_ENV=$VIRTUAL_ENV
export OLD_WSLENV=$WSLENV
export OLD_PS1=$PS1
[ "$(type -t python)" = 'alias' ] && export OLD_PYTHON=$(alias python)
[ "$(type -t pip)" = 'alias' ] && export OLD_pip=$(alias pip)
export VIRTUAL_ENV='C:\apps\python\venv'
export WSLENV=VIRTUAL_ENV
export PS1='(.wvenv) '$PS1
alias python='/mnt/c/apps/python/venv/Scripts/python.exe'
alias pip='/mnt/c/apps/python/venv/Scripts/pip.exe'
alias deactivate='unalias python
unalias pip
unset VIRTUAL_ENV
unset WSLENV
export VIRTUAL_ENV=$OLD_VIRTUAL_ENV
export WSLENV=$OLD_WSLENV
export PS1=$OLD_PS1
[ -z "$OLD_PYTHON" ] || "$OLD_PYTHON"
[ -z "$OLD_PIP" ] || "$OLD_PIP"
unset OLD_VIRTUAL_ENV
unset OLD_WSLENV
unset OLD_PS1
unset OLD_PYTHON
unset OLD_PIP'

I'm also using the portable version of Windows Python, hence the c:\apps\python path rather than wherever the standard install package puts it.

[junkmd]

I'm glad you were able to achieve what you wanted without changing the source code of this project.

In summary:

• This package still does not work on Linux or Mac versions of Python, and there are no plans to support them.
• To run this package, we need the official Python for Windows.

@ajkessel If this resolves your problem, please close the issue.

[ajkessel]

Unless I'm not looking in the right place, the FAQ doesn't mention WSL or Cygwin -- do you want to update it to clarify that even though both of those are running on a Windows host, they don't support comtypes, however, the user can still leverage comtypes from WSL/Cygwin by invoking Windows Python from within those environments?

[junkmd]

Indeed, it is important to inform that there is a chance to run comtypes even in environments other than “pure” Windows.

However, I am concerned that mentioning only WSL or Cygwin will lead to endless questions like “What about foo platform?”.

Therefore, I will abstract it a bit more and state in the FAQ: “In order to run a script that depends on comtypes, execute it using the python.exe built for Windows.”

What do you think?

[ajkessel]

To my knowledge, WSL and Cygwin are the only "Windows-like" environments whose Python implementations don't support comtypes, so I would still suggest calling them out. The user is in Windows, so, like me, may expect a Python module that relies on a Windows API would work. So I would still suggest calling out WSL and Cygwin.

Down the road, I do suspect there is some way to get comtypes to work "natively" in WSL or Cygwin, since they are both running on a Windows host. I'll do some more poking around to see if I can find any other WSL or Cygwin process that interacts with COM.

For example, this suggests it shouldn't be too heavy a lift in Cygwin.

[junkmd]

Down the road, I do suspect there is some way to get comtypes to work "natively" in WSL or Cygwin, since they are both running on a Windows host. I'll do some more poking around to see if I can find any other WSL or Cygwin process that interacts with COM.

I would like to leave that investigation to you. Please feel free to create a PR to add your findings to the documentation. Since I only use COM on pure Windows, investigating this myself is not a high priority for me, but I am happy to discuss or review your PR.

[ajkessel]

Understood. My suggestion for now is just that you mention WSL/Cygwin on the FAQ since those are the only common environments that run on a Windows box where this library won't work.