Fix comInterfaces_sconscript to no longer fail on wrapper module creation

[LeonarddeR]

Link to issue number:

Fixes #10228

Summary of the issue:

Comtypes wrapper module creation sometimes fails as the Python import mechanism creates a cache of paths we can import from, and that cache doesn't like frequent updates. See also enthought/comtypes#172

Description of how this pull request fixes the issue:

Monkeypatch comtypes.client._generate._my_import to clear the importlib cache first. Make sure comtypes is monkeypatches in our scons environment.

It also simplifies the patch that changes the wrapper generation directory, i.e. it no longer fiddles with sys.modules. Testing revealed that this is no longer necessary. Code revealed that thit is now done by comtypes.client._generate._my_import .

Testing performed:

Tested as part of #10169 appveyor build. See also #10228

Known issues with pull request:

None

Change log entry:

None

[michaelDCurran]

Do you think there would be any performance impact for this? no doubt importlib caching is there in Python3 for a reason, and if I understand correctly, any caching is dropped for every import of a comtypes COM interface. Could an alternative be that we only monkeypatch this for comInterfaces_sconscript? Or could this issue happen during NVDA running?

[LeonarddeR]

Do you think there would be any performance impact for this? no doubt importlib caching is there in Python3 for a reason, and if I understand correctly, any caching is dropped for every import of a comtypes COM interface.

I don't think it will have a very severe impact. Calling importlib.invalidate_caches doesn't have a noticeable delay, and if there is any impact, it is only at the start of NVDA.

Could an alternative be that we only monkeypatch this for comInterfaces_sconscript? Or could this issue happen during NVDA running?

Yes, I've seen this happening on an installed copy when trying to import an interface for which I did not have a wrapper yet.