Steps to reproduce:
Run system tests on appveyor.
Download and read the system test NVDA logs.
Actual behavior:
The logs show that an installed version of NVDA is running, but, certain modules, such as appModuleHandler is being picked up from the source directory!
For example, we know we're running the installed copy of NVDA because we see the following deprecation warning:
DEBUGWARNING - Python warning (00:39:17.317):
C:\Program Files (x86)\nvda\library.zip\extensionPoints\util.py:149: DeprecationWarning: inspect.getargspec() is deprecated since Python 3.0, use inspect.signature() or inspect.getfullargspec()
We can see that the path is pointing to NVDA's installation directory.
But, another traceback, that appears in the same log shows a different story:
Traceback (most recent call last):
File "nvda.pyw", line 221, in <module>
File "C:\projects\nvda\source\core.py", line 414, in main
desktopObject=NVDAObjects.window.Window(windowHandle=winUser.getDesktopWindow())
File "C:\projects\nvda\source\NVDAObjects\__init__.py", line 89, in __call__
appModule=obj.appModule
File "C:\projects\nvda\source\baseObject.py", line 46, in __get__
return instance._getPropertyViaCache(self.fget)
File "C:\projects\nvda\source\baseObject.py", line 149, in _getPropertyViaCache
val=getterMethod(self)
File "C:\projects\nvda\source\NVDAObjects\__init__.py", line 385, in _get_appModule
a=appModuleHandler.getAppModuleForNVDAObject(self)
File "C:\projects\nvda\source\appModuleHandler.py", line 105, in getAppModuleForNVDAObject
return getAppModuleFromProcessID(obj.processID)
File "C:\projects\nvda\source\appModuleHandler.py", line 119, in getAppModuleFromProcessID
mod=fetchAppModule(processID,appName)
File "C:\projects\nvda\source\appModuleHandler.py", line 174, in fetchAppModule
if doesAppModuleExist(modName):
File "C:\projects\nvda\source\appModuleHandler.py", line 159, in doesAppModuleExist
return any(importer.find_module("appModules.%s" % name) for importer in _importers)
File "C:\projects\nvda\source\appModuleHandler.py", line 159, in <genexpr>
return any(importer.find_module("appModules.%s" % name) for importer in _importers)
AttributeError: 'NoneType' object has no attribute 'find_module'
These paths are to modules in the git repository.
Also, the majority of the log messages have the word "external" after their log level, which denotes that the message is being logged from outside of this running NVDA's root directory.
Expected behavior:
Modules should not be loaded from the source directory, rather instead from library.zip in NVDA's installation directory.
System configuration
NVDA installed/portable/running from source:
Installed.
NVDA version:
threshold_py3_staging.
further info
This might explain the strangeness with _importers in appModuleHandler being None and or containing None objects in the list.
No doubt if we get to the root cause here we can revert pr #9800
My guess is perhaps some how sourceEnv is accidentally being compiled into the py2exe distribution and being executed? And since the system tests are executed from the root of the git repository, it would then pick up those python paths.
Steps to reproduce:
Run system tests on appveyor.
Download and read the system test NVDA logs.
Actual behavior:
The logs show that an installed version of NVDA is running, but, certain modules, such as appModuleHandler is being picked up from the source directory!
For example, we know we're running the installed copy of NVDA because we see the following deprecation warning:
We can see that the path is pointing to NVDA's installation directory.
But, another traceback, that appears in the same log shows a different story:
These paths are to modules in the git repository.
Also, the majority of the log messages have the word "external" after their log level, which denotes that the message is being logged from outside of this running NVDA's root directory.
Expected behavior:
Modules should not be loaded from the source directory, rather instead from library.zip in NVDA's installation directory.
System configuration
NVDA installed/portable/running from source:
Installed.
NVDA version:
threshold_py3_staging.
further info
This might explain the strangeness with _importers in appModuleHandler being None and or containing None objects in the list.
No doubt if we get to the root cause here we can revert pr #9800
My guess is perhaps some how sourceEnv is accidentally being compiled into the py2exe distribution and being executed? And since the system tests are executed from the root of the git repository, it would then pick up those python paths.