Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.98%. Comparing base (5267340) to head (96ef521).
⚠️ Report is 65 commits behind head on master.

@@           Coverage Diff           @@
##           master    #1232   +/-   ##
=======================================
  Coverage   87.98%   87.98%           
=======================================
  Files          60       59    -1     
  Lines       22985    22927   -58     
=======================================
- Hits        20223    20173   -50     
+ Misses       2762     2754    -8     

The best idea I have is adding "pywinauto" step to comtypes AppVeyor build matrix and run pywinauto tests there. Well, 2 pywinauto steps: for Py2.7 and Py3.10 should be enough. Also I know how to reduce the full pywinauto test suite to only "uia" backend related tests which will save time for comtypes CI.

Your proposal is attractive because it allows us to do what we want to do with less man-hours.

On the other hand, it doesn't feel right to test for pywinauto within comtypes.

It is better to use a way that can be used even if a package other than comtypes will be updated.

For example, pywin32 and six are third-party libraries that pywinauto also depends on, but I don't think that "put a install pywinauto test in their CI to make sure it works properly" proposal would be approved.

I agree that adding a non-env-dependent UIAutomationCore.dll test to comtypes, as simple as "just close an opened notepad app"(this is the code I assumed), to prevent "other dll APIs with comtypes is available, but only the UIAutomationCore.dll is not available" situation.

There are such things like dependabot and renovatebot that do something by updating dependency packages.
Or we might be able to do something with GitHub Actions.
I would like to suggest and consider using those tools.

Do you have any opinions?

The difference is that pywin32 and six packages have completely different maintainers and user bases. Though comtypes is not only pywinauto's dependency so in some sense you're right. I suggested the solution that is easiest for me to implement. And I've already started writing PowerShell scripts for it when I had 2 free hours.

Risk of absence of UIAutomationCore.dll is very low because it's built-in in the OS since Windows Vista. The only risk here: it might be renamed in the future Windows versions, but Microsoft do such things extremely rarely.

I'm not familiar with mentioned bots behavior yet. Maybe it makes sense. So more detailed suggestions are welcome.

@vasily-v-ryabov

Though comtypes is not only pywinauto's dependency

That was exactly the reason for the proposal not to test pywinauto in comtypes.

For example, I now use both comtypes and pywinauto, but used to use comtypes only for Excel operations. I was taking such developers into consideration.

Those bots are used for my application development.
The bots automatically submit PRs triggered by updating dependency packages.

Also,repository-dispatch is available in GitHub Actions Store, which seems to be able to trigger something.

If we can run automated testing (or script) triggered by these, we can do what we want without binding all comtypes developers to pywinauto.

Please wait as I am still investigating the specifics of how to do this, such as whether these bots can trigger only automated testing, or whether special tokens are needed for Actions.

I think one of the right ways would be writing comtypes unit tests for UIAutomationCore.dll which is part of OS. But it takes time, and we have big number of ready-to-use tests on top of UIAutomationCore.dll in pywinauto. In this case pywinauto plays role of test framework. Only cyclic dependency makes this way a bit wrong.

I have been repeatedly close and re-open this PR for Error uploading artifact to the storage: Remote server returned 503: Service Unavailable.

I think the annoying ping has send to community members. My apologies.